Design Uber 🚕
rider ⇄ driver matching · real-time location · hellointerview breakdown
1Requirements
Functional
- Pickup + dest → fare estimate
- Request ride from that estimate
- Match rider ↔ nearby available driver
- Driver accepts/declines → pickup → dropoff
✗ ratings, scheduling, ride tiers
Non-functional
- Match < 1 min — or fail
- Strong consistency → 1 driver, 1 ride
- Peak: 100k reqs, same location
✗ GDPR, redundancy, CI/CD
2Entities & data model
Ride rideId · riderId · driverId? · fareId
source · destination · status
Fare id · userId · source · destination
price · eta
Driver id · name · vehicle
Rider id · …
Location driverId · lat/long · ts
driverId is nullable until matched
Fare = the quote · Ride = the trip · Location = the hot, high-write one
status: requested → matched → accepted → in-progress → completed
3API
POST /fare {pickupLocation, destination} → Fare getFareEstimate()
POST /rides {fareId} → Ride
POST /drivers/location {lat, long} → OK updateLocation()
PATCH /rides/:rideId {accept | deny} → Ride acceptOrDeclineRide()
★ Never take driverId/riderId from the body — read it from the JWT.
A client-supplied id lets anyone move any driver.
4High-level design
┌────────────── 3rd-party Maps ◀─┐
Rider ─┐ ┌───────────────┐ │ │
├──▶│ API GATEWAY │──▶ RIDE SERVICE ─────────────▶ DB (Dynamo/Postgres)
Driver ─┘ │ routing· auth │ fare est · create ride Fare + Ride
▲ │ rate-limit │ triggers match workflow
│ └───────────────┘ │
│ │ ▼
│ │ [ MATCH QUEUE ]
│ │ │
│ │ ▼ ┌─▶ DISTRIB. LOCK (Redis)
│ │ MATCHING SERVICE ──┤ "driver already asked?"
│ │ └─▶ LOCATION DB (Redis)
│ └──▶ LOCATION SERVICE ─────────────▶ "closest drivers"
│ updateLocation()
└── NOTIFICATION SVC (APNs/FCM) ◀── "accept / decline?"
★ Redis appears twice — different jobs
- Location DB — geohash sorted set, "who is near this point"
- Distributed Lock — driverId key + TTL, "is this driver already claimed"
- 10 M drivers · 5 s ping → 2 M writes/sec · naive DynamoDB ≈ $200k/day
Deep dives
the part the interview is actually scored on
1Geospatial — 2 M writes/sec
Why it breaks: B-trees order in 1-D. "Drivers within 2 km" is a 2-D range query — the index can't serve it.
- Redis geo — GEOADD write · GEOSEARCH radius read
- Geohash packs lat/long → 52-bit int = sorted-set score
- GEOADD overwrites → always current position, no history to prune
- TTL drops drivers offline > 30 s automatically
- Durability? don't care — one 5 s ping cycle rebuilds everything
alt (good, not great): Postgres + PostGIS, quadtree index
2Adaptive ping intervals
- Fixed 5 s for everyone wastes battery + bandwidth
- Client varies rate by speed, heading, nearby demand, idle vs active
- ★ not every optimisation is server-side
3Double-booking a driver
Race: two Matching instances pick the same driver at the same instant.
lock(driverId, TTL 10s) → notify → accept → update ride + release
└─ silence → TTL expires → driver free
- Redis distributed lock, key = driverId, TTL 10 s
- TTL does double duty: mutual exclusion and the response timeout
- Service crashes holding it? Expires itself — no orphaned driver
4Peak demand — lose nothing
- Kafka ahead of Matching; commit offset only after a successful match
- Crash before commit → redelivered, not lost
- Autoscale workers on queue depth · partition geographically
- FIFO → priority queue so one slow request can't head-of-line block
5Driver doesn't respond
- Durable execution — Temporal / AWS Step Functions
- send to ranked driver → wait 10 s → accept ✔ · decline/timeout → next driver
- State persisted → survives crash, resumes where it stopped
- Removes the hand-rolled delay-queue + race-condition mess
6Scaling for latency
- Geo-shard services, queues, DBs — shorter client→server hop
- Read replicas for read throughput · consistent hashing to balance
- Scatter-gather only when a radius crosses a shard boundary
Level bar
- E4: working HLD, know you need a geo index, some driver lock
- E5: 2+ deep dives in detail, argue trade-offs
- L8+: raise 3+ unprompted, from real experience
Recall in 20 s
Redis geohash → 2M w/s · lock + TTL → no double-book ·
Kafka, late offset commit → no lost reqs · durable workflow → timeouts ·
geo-shard → latency.