What a Proximity Service Does

In one line: that building block asked "how do I get from A to B?" This chapter asks "what is near me?" — and although both are geographic, they are different problems with different answers.

The product

Yelp connects consumers with local businesses. Users can discover places, make reservations, and view business information, such as photos and reviews. Similar location-based services include Foursquare and Google Nearby.

The interaction is short:

User types:   "cafe"
User is at:   Seattle
System returns: cafes within a radius, centred on the user

Users submit a search query or GPS coordinates, and the system returns nearby points of interest. The core functionality depends on a proximity server that resolves nearby locations. Designing this system is challenging because the architecture must efficiently query massive datasets to return locations within a given radius. This requires spatial indexing techniques such as quadtrees or geohashes to minimize latency when filtering millions of locations.

The whole chapter is in that last sentence

Note what filtering millions of locations by proximity, fast.

Not storing them — 500 million places is under a terabyte, as the estimation will show. Not serving them — the traffic is unremarkable. Finding the relevant few among the many, by a criterion that no ordinary index supports.

That is worth stating plainly, because it tells you where the design effort goes. Nine of this chapter's lessons are about one question: how do you organize 500 million coordinates so that "everything within 5 miles of here" is cheap?

Everything else — the API, the schema, the read and write servers — is conventional and takes a lesson each.

Why this is not the Google Maps problem

Both chapters partition the world into segments. It is tempting to treat this as the same design, and the differences are what make it interesting.

The deepest difference: there is no path to compute

In that building block, the answer to a query was a route — an ordered sequence of edges whose total weight had to be minimized. That is why the design revolved around precomputing shortest paths, and why Dijkstra's inability to parallelize was the central constraint.

Here there is no path. The answer is a set: every place whose coordinates fall within a radius. Set membership, not optimization.

That changes the entire character of the solution. You do not precompute answers, because the number of possible (location, radius, category) queries is unbounded. Instead you organize the data so any such query touches only a small part of it.

Maps needed an algorithm. Yelp needs an index.

Which is why the chapter's real subject is data structures — a range query, then static segments, then quadtrees — rather than traversal strategies. And why the two chapters converge on similar-looking pictures of a partitioned globe for entirely different reasons.

Density is the enemy here, and it was not there

Both chapters partition space. Only this one is destroyed by uneven density.

Maps could tolerate uniform 5×5-mile squares reasonably well, because a segment's cost is its road graph, and even a dense city's road graph fits in memory. The chapter noted non-uniform segments as a refinement.

Here, uneven density is fatal rather than suboptimal, because the thing you are counting is places, and places cluster far more extremely than roads do:

• A 5×5-mile square in Manhattan may hold tens of thousands of restaurants, cafes, and shops.
• The same square in rural Nevada may hold three.

A search in Manhattan scans an enormous list; a search in Nevada finds nothing and must widen. The same fixed geometry fails at both ends simultaneously.

That single observation is what drives the chapter from static segments to quadtrees — a structure whose cells are sized by how many places they contain rather than by how much ground they cover. Watch for the moment the design stops partitioning space and starts partitioning data. That is the pivot.

Two kinds of user, which the requirements will make explicit

There can be two types of users: business owners who can add their places on the platform, and other users who can search, view, and give a rating to a place.

These have almost nothing in common operationally. Business owners write — a handful of new places per day across the entire platform. Consumers read — tens of millions of searches.

The estimation will show the asymmetry starkly: five new places a day against 60 million daily users. That is a read-to-write ratio of roughly ten million to one, and it justifies the design's separation of read servers from write servers before a single line of the architecture is drawn.

The ratio is worth computing early, because it rules things out. At roughly a thousand reads per write, review writes land near one per second — which any relational database absorbs without help. Recognizing that a message queue and sharding are unnecessary here is a stronger signal than proposing them.

Next: requirements and the estimation, which contains a striking mistake.