Skip to main content
Proximity Service (Yelp, Nearby)lesson 1 of 4 · 2 min read

Sizing the Problem

Volumes first

Start with volumes, because they decide the shape of your answer before a single box gets drawn.

Assume 200 million businesses worldwide and a hundred million daily users each running five nearby searches. That is 500 million searches a day, about 5,800 a second on average, and call it 20,000 a second at peak.

Storage is small, which surprises people. A business row with its name, address, coordinates, category, hours and rating is roughly 5 kilobytes, so 200 million of them is about a terabyte.

Read what that means: it fits on one large machine, so storage is not your constraint. Queries a second is.

The ratio that shapes everything

Look at the write rate, because it shapes everything. New listings and edits run maybe a hundred thousand a day, roughly one a second.

Compare that against 20,000 reads a second and your ratio is twenty thousand to one. A workload that lopsided tells you to optimise reads relentlessly and let writes be slow, which licenses aggressive denormalisation, heavy caching, and a search index built in the background.

Have one more figure ready: your latency budget. Nearby search is interactive, so 100 milliseconds end to end is the target, leaving roughly 50 for the query itself once you subtract network and rendering.

Say that budget out loud in an interview, because it converts a design preference into a requirement. It is exactly what rules out scanning a latitude band and filtering 60,000 rows.

the shape of it
100M users5 searches a day20k reads/secat peak1 write/sec100k edits a day20,000 : 1read to writeDenormalisecache hard, rebuild asyncthe ratio decides
step 1 of 3
The read-write ratio, not the storage size, is what picks the architecture.

Worked example

Ana is asked this in an onsite and opens with the estimate rather than a diagram. 200M businesses at 5 KB is 1 TB, so storage fits anywhere and is not interesting. 20k searches per second at peak against about 1 write per second is a 20,000 to 1 read-write ratio. She says the consequence out loud: the search path can be a denormalised, cached, asynchronously rebuilt index, because staleness of a few seconds on a new restaurant listing is invisible to users and the read savings are enormous. The interviewer stops her there and says that is the answer they were looking for, and the rest of the hour is about the index. The candidate who starts by drawing services rarely gets to say any of that.