Skip to main content
A simplified reconstruction of Uber from their published architecture; numbers are illustrative. Driver pings outnumber rider requests 13 to 1 and ride a Kafka-style stream; at 4x the geo consumer lags and dispatch matches on stale positions without a single rider-facing error. Crash the payment processor and the breaker contains it.

What to watch

One rider request touches four services before an offer comes back. The slowest of them sets the wait, so a match happens at the speed of the weakest link here. Drag the load to 4x and watch payments. Each charge takes 200ms and only four run at once, so it tops out near 20 a second. The breaker in front notices and starts failing fast, which beats every trip request piling up behind a slow card network. The location index is split by map cell. Give it a hot key and the whole city crowds into one cell, so that one shard saturates while the rest sit idle. 400 driver pings a second go onto one stream, and three readers consume it on their own clocks. If the map updater falls behind, dispatch quietly matches on stale positions and nothing on the rider path shows an error.

What it is made of

Under load

Measured by running this design through the simulator at multiples of its own offered rate of 430 requests a second. Twenty seconds of simulated time, one fixed seed, so the same numbers come out every time.

Open this example

Load Uber: ride dispatch from the Examples menu and drag the traffic slider yourself.