Design nearby places (Yelp / Google Maps places)

A plain B-tree on (lat, lng) does not work well: a range on latitude plus a range on longitude scans a wide strip. You need a structure that maps 2D closeness to 1D keys. Geohash interleaves latitude and longitude bits into a base-32 string; a shared prefix means nearby, so you can store places by geohash prefix and query the user's cell plus 8 neighbours (neighbours are needed because two points across a cell edge can share no prefix). Precision 6 gives ~1.2 x 0.6 km cells, precision 5 ~4.9 x 4.9 km. A quadtree splits a region into four until each leaf holds at most ~100 places, so dense Connaught Place gets tiny cells and rural Rajasthan big ones; it adapts to density but must be built in memory and is harder to update and shard. Google S2 (and Uber's H3 with hexagons) are hierarchical cell systems on the sphere with good coverings for circles and polygons and 64-bit cell IDs that sort well. Good answer: S2 or geohash cells as keys in an in-memory index, with an explanation of why neighbours and exact distance filtering are needed.

The full geo index is about 5 GB: 200M places x ~24 bytes. That fits in memory on any modern server. So instead of sharding by region (which makes queries near region borders touch two shards and creates hot shards for Mumbai and Delhi), give every search node a full copy and scale reads by adding nodes. Updates are rare (~100/s), so each node consumes the change stream from Kafka and patches its copy, and a nightly snapshot from the database rebuilds it from scratch to remove drift. A new node starts by loading the latest snapshot from S3 and then replaying Kafka from the snapshot's offset. If the place count grew 10x and the index no longer fits, shard by S2 cell ranges at a coarse level and route queries to the one or two shards their covering touches. Saying 'it fits in memory, so replicate it' with the numbers is a strong signal of estimation-driven design.

Pure distance sorting is rarely what users want: the closest restaurant may have a 2.1 rating. A useful score blends distance decay, rating (with Bayesian smoothing so a 5.0 from 2 reviews does not beat a 4.5 from 3,000), popularity, open now and text relevance. Elasticsearch function_score with a gauss decay on distance plus field value factors expresses this well for text queries. Density varies hugely: within 500 m of Bandra station there are thousands of places, while a highway stretch may have none within 10 km. Use an adaptive radius: start with a small covering, and if too few candidates match the filters, expand to coarser cells. Cap the candidate count per query (e.g. 1,000) by taking the best-scored places per cell, which you can pre-sort by popularity inside each cell list. For India, addresses are weak, so landmarks ('near Hanuman temple') in search fields and user-reported pin corrections matter.

Reviews are write-heavy compared with places and have a natural partition key, place_id, with time-ordered clustering, so Cassandra or DynamoDB fits. Do not recompute the average on every read. When a review is created, publish an event; a consumer increments rating_sum and rating_count for the place (idempotently, keyed by review_id so retries do not double count) and updates the place row and search index. Spam and fake reviews are a real problem: limit reviews per user per place, weight by reviewer trust, detect bursts from new accounts, and hold suspicious reviews for moderation before they count. Show a Bayesian average so a new place is not ranked at the top on one 5-star review.

Geohash is simple and works in any key-value store or Redis GEO, but cells are distorted and need neighbour lookups. A quadtree adapts to density but is in-memory and awkward to update. S2/H3 give better coverings and hierarchy at the cost of a library dependency. Pick S2 or geohash and justify it.

PostGIS with a GiST index handles nearby queries well up to a few thousand QPS and is a great v1. At ~100k QPS, a replicated in-memory index is cheaper and faster, with Postgres kept as the source of truth.

Patching the index from Kafka gives minutes of freshness; a nightly rebuild alone is simpler but a new restaurant would wait a day. Use both: streaming patches plus nightly rebuild for correctness.

Elasticsearch can do both and is enough for text queries. For category-only 'nearby' queries the in-memory index is faster and cheaper, so use it for the hot path.

Queries around airports, stations and malls hit the same cells. Cache results per (cell, category, sort) for 5-10 minutes; place data barely changes.

Each search needs details for 20 places. Use batch reads (MGET) from Redis and keep the summary fields needed for a list card inside the geo index entry, so the list renders without the details call.

Index grows to ~50 GB: still fits in RAM on large machines, or shard by coarse S2 cell ranges with routing by covering.

Reads are unaffected (geo index and caches serve them). Writes fail over to a replica promoted by the database's HA setup; edits queued by clients retry with idempotency keys.

It reloads the snapshot from S3 and replays Kafka; the load balancer keeps it out of rotation until it reports ready.

Text search falls back to the geo index with name prefix matching on the candidate set; results are less relevant but still useful.