“Show me the top 10 players, and tell me where I rank.”

Two sentences. They sound like the same problem and they are not, and the second one is why this design exists.

Finding the top 10 of anything is easy — you keep a small heap. But telling one player they are #4,328,911 out of 25 million, updated in real time as everyone else keeps scoring, is a genuinely hard query. There is no shortcut: to know someone’s rank you have to know how many people are ahead of them, which means knowing about everyone.

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.

It’s 11:59 PM on Black Friday. Your e-commerce platform has been running smoothly all day. Then at midnight, 500,000 shoppers simultaneously hammer your /checkout API. Your servers start queuing requests. Then they start dropping requests. Then they crash. Every second of downtime costs thousands of dollars in lost sales.

Meanwhile, a competitor’s site — running the exact same infrastructure — handles the load just fine. The difference? They had a rate limiter.