Design a service that returns businesses within a given radius of a user's location, with filters and ranking, for hundreds of millions of places and very high read traffic.

• 200M places × ~1 KB details = 200 GB (relational + cache); geo index entries ~50 B each = 10 GB — fits in memory on a few nodes.
• 20k QPS reads; writes ~10/s.
• Geohash precision 6 (~1.2 km × 0.6 km) → ~200M / (cells covering land) ≈ tens of places per urban cell, more in dense cities → query 9 neighbouring cells and filter by exact distance.

GET /v1/search/nearby?lat=&lng=&radius=1000&category=cafe&limit=20&cursor=
→ { places:[{id, name, distanceM, rating, lat, lng}], nextCursor }
GET /v1/places/{id}
POST/PUT/DELETE /v1/places  (owner/admin)

places   (place_id, name, lat, lng, category, rating, address, hours, ...)
geo_index(geohash VARCHAR(6), place_id)  -- indexed on geohash; or a quadtree in memory
cache    Redis: cell:{geohash} → [place_ids], place:{id} → details

1. Write path: place service writes to the places DB (primary) and updates the geo index; replicas serve reads. Writes are rare, so no fancy pipeline.
2. Read path: location service computes the geohash of the query point and its 8 neighbours at the precision matching the radius (larger radius → shorter geohash), fetches place ids for those cells (cache → DB), computes exact haversine distance, filters, ranks, paginates.
3. Index choices: geohash (string prefix ranges, simple, works in any DB with a B-tree); quadtree (in-memory tree that adapts to density — dense cities get deeper nodes); Google S2 / H3 cells (hierarchical, better edge handling). Geohash on a DB index is enough at this scale; quadtree in memory if you need sub-10 ms.
4. Caching: cell → ids in Redis with TTL; place details cached separately so a place update invalidates one key.
5. Ranking: distance, rating, popularity; can be a small model.

Why 9 cells: a point near a cell edge has neighbours in adjacent cells; querying the 3×3 block guarantees coverage for radius ≤ cell size. For larger radii, drop to a shorter geohash.

Precision vs density: fixed geohash precision gives huge cells in Manhattan and empty ones in the desert; a quadtree subdivides until each leaf holds ≤ 100 places. Trade-off: quadtree must be rebuilt/kept in memory.

Pagination: cursor = (score, place_id) after ranking; recompute per page (cheap) rather than storing result sets.

• Redis down: replicas serve cell queries directly (indexed), higher latency but available.
• Replica lag spike: acceptable for this workload; alert if > minutes.
• Bad data (place at 0,0): validation at write; geo bounds checks.