Google Maps has about a billion daily active users, covers 99% of the world, and takes in something like 25 million updates a day.

We’re going to build a simplified version. Three features:

1. Location updates — the client reporting where you are
2. Navigation — a route from A to B, with an ETA
3. Map rendering — the actual map on your screen

Each one turns out to be a different kind of problem. Rendering is a storage and CDN economics problem. Navigation is a graph algorithms problem, and the graph is far too large to hold in memory. Location updates are a write throughput problem — a million per second at peak.

In the last chapter we found restaurants near you. This one looks almost identical — find friends near you — and it is a completely different problem.

Restaurants do not move. A restaurant’s location is written once and read a billion times, which is why that design could precompute an index, cache it globally, and rebuild it overnight.

People move. Every user is emitting a new location every thirty seconds, and every one of those updates has to reach a few hundred other people right now. The index is obsolete before you finish building it.

You open Yelp and tap restaurants near me.

Under a second later, you have a ranked list. Somewhere behind that tap, a system just searched 200 million businesses, found the handful within 500 metres of you, sorted them by distance, and shipped them back — while doing the same thing for a few thousand other people that second.

The obvious implementation is a WHERE clause on latitude and longitude. It does not work, and why it does not work is one of the more interesting failures in system design: the query is perfectly indexable in each dimension separately, and that turns out to be useless.