20k/s
searches to plan for at dinner time
100M daily users × 5 searches ≈ 5,800 a second, and dinner runs 3×. Writes are about 46 a second: this is a read problem.
Why not index latitude and longitude?
Bad: B-tree on lat, lng
A ±2 km box reads a planet-wide band, 12,000× the circle.
Good: Make 2D indexable
Nearby points get nearby keys, or a tree splits space.
A place 22 m away can sit in the next cell
Geohash turns a point into a string where a prefix is a cell. So you always scan your cell and its 8 neighbours.
200 million places, one query, about 90 scored
Put geo, text, price, rating and hours on one search document. Yes-or-no filters shrink the set before anything is scored.
Two reviews from the owner’s cousins average 5.0; 3,000 reviews average 4.6. Raw averages pick the cousins.
Bayesian average
Start every place with 20 imaginary reviews at the typical 3.8. Now it’s 3.91 against 4.59.
A fixed 2 km is wrong in the city and the desert
Solve π r² × density = 200 for r. About 1.3 km in Connaught Place, 36 km in rural Rajasthan. One query either way.
Fresh index, no hot row
- CDC tails the database log into Kafka
- An indexer rebuilds changed documents in seconds
- Reviews go via an outbox to an aggregator
- 1,000 reviews an hour → 60 index updates
Remember
Keep places in PostgreSQL. Search a separate geo index with one query: filters, then text × distance decay × Bayesian rating. Radius from density, freshness by CDC, caching per geohash cell.