1Context and scope
Thousands of drivers send their location every few seconds; riders ask for an ETA and request rides. Matching finds the nearest available drivers in a geospatial index that is updated continuously from the location stream. This design covers location pings, ETAs and ride requests at browser scale, based on Uber’s engineering posts about H3, dispatch and the trips store.
2Goals and non-goals
Goals
- 5,000 requests a second: 60% driver location pings, 30% ETA queries, 10% ride requests.
- Success at least 99%, p99 at most 500 ms, Apdex at least 0.90.
- Location updates reach the index through Kafka; notifications are sent asynchronously.
Non-goals
- Pricing and surge.
- Payments and payouts.
- Maps rendering and routing itself.
3Capacity estimate
| Quantity | Value | How |
|---|---|---|
| Location pings | ≈ 3,000/s | 60% of 5,000, into 64 Kafka partitions |
| Index updates | 128 workers at ≈ 2 ms | about 64,000 writes a second of headroom |
| ETA queries | ≈ 1,500/s | an 8 GB cache with a 30-second TTL in front of the index |
| Ride requests | ≈ 500/s | each: an index query, a Postgres write, a notification job |
| Geospatial index | 2,000 slots, 32 vCPU, 1 ms CPU | index queries plus 3,000 updates a second: about 4.5 vCPU busy |
| Notifications | ≈ 500/s | 64 workers; push to rider and driver |
The rest of the doc
The design · Key concepts · Alternatives considered · Failure modes and fixes · Try it in the lab · Check yourself · Further reading
Unlock the Uber design doc
Every component and why it is there, the capacity numbers behind it, what breaks when you push it and how to fix it, and the same system open in the lab to break and fix yourself. Paid once, on your account.