44. Design Ride-Hailing with Surge Pricing (Uber / Rapido)
1
The interview prompt2
44.1 What do you ask first?3
44.2 How big is this, really?4
44.3 What are the doors?5
44.4 What do we store?6
44.5 What does the whole system look like?7
44.6 How are location updates handled?8
44.7 How does matching work?9
44.8 How does surge pricing work?10
44.9 How does the trip state machine work?11
44.10 What would you say in the last five minutes?12
Score yourself13
Variations to practise14
Sources15
Code lab44. Design Ride-Hailing with Surge Pricing (Uber / Rapido)
44.2 How big is this, really?
3 min read+10 XP
Step 2: Estimates (5 minutes)
Assume about 100 bytes per location update, a peak factor of 4 for ride requests, and 5 road-ETA lookups per match.
| What | Working | Result |
|---|---|---|
| Location updates | 1,000,000 ÷ 4 s | 250,000 a second |
| Location data | 250,000 × 100 bytes | ≈ 25 MB/s ≈ 2 TB a day (history, analytics) |
| Ride requests | 20 million ÷ 86,400 × 4 | ≈ 230 average, ~1,000 a second at peak |
| ETA lookups | 1,000 × 5 | ≈ 5,000 a second |
| Index memory | 1 million drivers × ~100 bytes | ≈ 100 MB: tiny, per city even smaller |
What the numbers say, out loud:
- "Location writes dominate: 250,000 a second, but each only needs to update the latest position in memory (Chapter 18). History goes to a stream, not the main database."
- "Matching is light in volume (about 1,000 a second) but latency-critical, and needs road ETAs, not straight lines."
- "Everything is local to a city: shard the index and matcher by city or region (Chapter 18's sharding by region)."
Interviewer pushback:
- "Why 4 seconds?" → It's a trade-off between map smoothness and battery and data. Phones can report less often when a driver is idle and more often during a trip.
Memory code: "Locations are many and disposable; rides are fewer and precious."