Uber - the case study

The whole set on one board. This lesson tells the story of the one question the whole system exists to answer, and by the end you’ll know the handful of tricks that make answering it, a million times a second, possible.

Boards

Before you start. You need to already be comfortable with the idea that a system can be forced to choose between always answering and always being right the moment a network breaks, and that splitting a huge pile of data across many machines by some key is what makes a big system fast at all. Nothing else is assumed - every other idea here is shown working before it’s named.

The idea in 30 seconds

Uber’s whole design starts from one question asked off a phone: which car can reach this exact spot soonest?
Checking every car for every question doesn’t scale; chopping the map into fixed tiles (cells) and filing each car under the one it’s in turns the question into a lookup.
The same tile also decides which single machine handles it, so a nearby question and a nearby car always land in the same place.
Booking a driver, tracking a ride’s stage, and moving money are the three places this design insists on being exactly right. Everywhere else, being a few seconds stale is fine.
A reservation locks one driver before anyone is told; a state machine tracks a ride through fixed stages and survives a crash; an idempotency key and a balanced ledger keep money from ever moving twice.
A price that just mirrors supply and demand spikes and collapses within seconds; capping and smoothing it turns a lottery into a signal a driver can act on.

Read the story · Skip to the numbers