Design a Proximity Service (Yelp / Nearby)

Geo, Maps & MarketplacesMediumdesign-proximity-service

Design a Proximity Service (Yelp / Nearby)

Design 'what's near me' over hundreds of millions of mostly-static places: radius search, category filters, and ranking, at read volumes that dwarf the write rate.

GeohashQuadtreeRead-Heavy CachingStatic Index Rebuild

Traffic & Capacity Estimates:

200M places · 5k searches/second · 100:1 read:write · results within 50ms

Functional Requirements

•Return places within a radius of a coordinate, filtered by category and open-now status.
•Rank results by a blend of distance, rating, and popularity.
•Support pagination and radius expansion when a dense filter returns too few results.
•Reflect business detail edits within minutes.

Non-Functional Requirements

•Search latency under 50ms at p99.
•Uniform performance in both dense city centres and sparse rural areas.
•Index rebuilds must not interrupt serving.

Back-of-the-Envelope Math

200M places * 1 KB = 200 GB of place data; the spatial index itself is a few GB and fits in memory per node.
A geohash cell in Manhattan may hold 10,000 places while one in Montana holds 3 — fixed-size cells guarantee both a hot shard and empty ones.

Key Architectural Trade-offs

Fixed-precision geohash prefixes are trivially shardable and distribute terribly in cities; adaptive quadtrees balance density and cost more to maintain.
Because places rarely move, the spatial index can be rebuilt offline and swapped atomically — a luxury the ride-hailing version does not have.
Searching a single cell is fast and wrong at boundaries; searching the cell plus its eight neighbours is correct and multiplies the read cost by nine.

Click or drag a component onto the canvas, then connect the handles to draw the data flow.

3 nodes · 2 edges

Components · 35

Client & Edge4

Compute & Gateway7

Storage & Caching11

Messaging & Streaming6

Coordination & Ops5

Intelligence2

React Flow