Hard · Mobility and logistics
Ride-hailing dispatch
You run dispatch for a big metro area. About 100,000 drivers send a position every 4 seconds, and riders ask for cars near them. When a stadium empties, thousands of riders ask for a car from the same few blocks at the same moment. Match riders to drivers fast, and never charge a trip twice. Practise this hard system design problem for free with a Google or GitHub account.
The brief
You run dispatch for a big metro area. About 100,000 drivers send a position every 4 seconds, and riders ask for cars near them. When a stadium empties, thousands of riders ask for a car from the same few blocks at the same moment. Match riders to drivers fast, and never charge a trip twice.
Think of an app like Uber.
Users, scale and requirements
- Who uses it
- 15 million riders and 600,000 drivers a month, 100,000 drivers online at peak (approx.)
- Audience in plain numbers
- 15,000,000 people per month
- Normal peak
- ≈ 30,000 requests per second
- Request mix
- Location ping: 80%; Read: 12%; Write: 4%; Payment: 0.5%; Notification: 3.5%
- Speed for 99 of 100 requests
- Read: ≈ 300 ms; Write: ≈ 300 ms; Payment: ≈ 3,000 ms
- Successful requests
- 99.9%
- Data safety
- No acknowledged write may be lost.
- Monthly budget
- ≈ $40,000
- Data at rest
- ≈ 2 TB
- Where users are
- North America: 100%
- Home region
- North America
- Waiting deadlines
- Location ping: 900 seconds; Read: 900 seconds; Write: 3,600 seconds; Payment: 3,600 seconds; Notification: 900 seconds
- Fresh reads
- People must see their own changes. At most 0.1% of reads may be stale in the model.
- Personal reads
- 80% of reads are private; a shared public copy cannot answer them.
- Required proofs
- Managed encryption keys; Personal data isolated
≈ marks an approximation, just as in the game. Waiting deadlines measure the age of queued work and are separate from interactive response time.
- 100,000 drivers x one ping per 4 s is about 25,000 pings a second. Locations are 80 percent of traffic.
- Rider reads are nearby-car lookups and price quotes. Writes are ride state changes: request, accept, start, end.
- All numbers are rough approximations.
- Notification speed measures provider acceptance. Device receipt is outside this traffic model; check expiry, provider outcome and retries in the correctness trace before claiming delivery guarantees.
Questions that shape the design
How accurate must the car positions be?
A rider sees cars that are a few seconds old. Dispatch itself needs the freshest position of each driver.
What happens at a stadium exit?
Thousands of requests come from one small area in a few minutes. One map cell can get a third of all lookups.
Can a ride request be lost?
No. Once a rider is told a car is coming, the trip record must survive a server failure.
Is a duplicate charge ever acceptable?
Never. A trip is charged once, even if the network retries.
The traffic day
Morning and evening commute peaks. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.
08:10 · Zone outage
An availability zone loses power or network access.
Duration: ≈ 3,600 seconds.
17:45 · Hot key
One item gets a huge share of traffic: a celebrity profile, one product, one merchant.
Affected share: 30%. Duration: ≈ 3,600 seconds.
22:45 · Flash crowd
A scheduled launch brings a sudden rush of requests.
Traffic for Read, Write, Notification reaches 6 times the scheduled load; rises over 60 seconds, holds for 1,800 seconds and eases over 1,800 seconds. Other request types keep their scheduled load.
What a strong design has to handle
- Location pings are four out of five requests and each one is tiny. Do they belong in the same database as ride records?
- Claim a driver once despite stale locations and concurrent matching.
- Reading a position back with consistency level ONE is fast and can be a few seconds stale. A driver position is stale after 4 seconds anyway.
- A 5 second cache means a rider can see a car that just took another trip. The match step re-checks with the driver before it commits.
Make a prediction, run a full traffic day, then compare the result. The in-game editorial opens after a finished day and includes measured reference designs.
Concepts to practise
Related problems
- Hard
Battle royale launch
On launch night millions of players queue for matches of 100. Each match streams positions many times a second, the lobby shows the live player count, and one patch notes page is opened by everyone. Connections must stay open, a match server dying must preserve acknowledged progress within the stated recovery point, and a few hot items, like the daily reward, are hit by everybody.
- Medium
Food delivery
You run food delivery in a few big cities. People browse menus, pay for an order, and watch a courier move on a map. Dinner time is brutal, and the payment company sometimes slows down. Nobody may be charged twice, and no paid order may vanish.
- Medium
Rate limiter for a public API
Developers call your public API from scripts and apps. A few misbehaving or malicious clients can crowd out everyone else. Build limits that are fair, fast and cheap, and that survive a retry storm.
- Hard
Object storage service
Customers store billions of files, from tiny pictures to huge videos, and fetch them by name. The service must never lose a file, scale without a limit and stay cheap. Most files are written once and rarely read again.