Design Real-Time Location Tracking

"Design real-time location tracking" is the storage-and-query half of Uber's mobility stack, the companion to ride matching. Where matching asks "which available drivers are nearest this rider right now," tracking asks a quieter set of questions about the same stream of location pings. Show me where this driver is on the map this second. Replay the path a trip took from pickup to drop-off. Show a dispatcher, or a surge model, how dense the supply of drivers is across a city right now. And keep enough of that location history around to answer questions about the last month. Every one of those is fed by the same source: drivers' phones reporting their position over and over, the whole time they are online.

Anchor on scale before drawing anything, because the scale drives every decision that follows. Uber has millions of active drivers, and each phone reports its location roughly every 3 to 4 seconds while the driver is online. Do that arithmetic. Millions of drivers, each writing a new position every few seconds, lands on the order of a million location writes per second flowing into the system, sustained all day. That is a write firehose, a stream of writes so large and so constant that it dominates every design choice. On top of it sit perhaps a hundred thousand concurrent active trips whose live paths need tracking. A thirty-day window of history also has to stay queryable for any driver or trip, without the storage bill growing without bound.

Not every read wants the same data, and that splits the whole design. A live map needs each driver's single latest position, and last second's value is junk the moment a newer one lands. A trip replay or a thirty-day lookup needs a durable record over time, but not every ping, since a path sampled every twenty or thirty seconds traces the same route. A heatmap needs neither: just a count of how many drivers sit in each patch of the map right now. One write firehose, three differently-shaped reads.