System design interviews are hard because they're open-ended. Here's exactly how I'd walk through designing Uber's ride-sharing platform in 45 minutes — the same approach that helped me clear my interviews.
The Framework (5 phases, 45 minutes)
| Phase | Time | What |
|---|---|---|
| Requirements | 5 min | Scope it down to 3 functional + 3 non-functional |
| Entities + API | 5 min | 5-6 entities, one endpoint per requirement |
| Architecture | 15 min | Build incrementally, one FR at a time |
| Deep Dives | 15 min | Bad → Good → Great for 2-3 hard problems |
| Wrap-up | 5 min | Summarize tradeoffs |
Requirements I'd Pick
Functional (top 3):
- Riders request a ride → get matched with nearest driver in <30s
- Real-time location tracking — drivers send GPS every 3-5s
- Drivers accept/decline, navigate, complete trip
Non-functional:
- 500K location writes/sec (2M drivers × 1 ping/4s)
- No double-booking (strong consistency on driver assignment)
- 99.99% availability during peak
The Architecture (built incrementally)
Step 1: Matching a Rider with a Driver
The first question: how do you find the nearest driver?
You can't query Postgres with WHERE distance < 3km at 500K writes/sec. The answer: Redis Geo.
Redis Geo stores coordinates using geohash encoding. GEORADIUS returns all drivers within a radius in O(N+log M) time — sub-millisecond at scale.
Flow:
- Rider taps "Request Ride" → hits API Gateway
- Matching Service asks Redis Geo: "drivers within 3km of pickup"
- Ranks by ETA (not raw distance — a driver 500m away in traffic is worse than 1.2km on a highway)
- Locks the best driver with
SET NX EX 20(atomic distributed lock with 20s TTL) - If lock acquired → send ride offer. If not → try next driver.
Step 2: Real-Time Location Streaming
2M drivers × 1 ping/4s = 500K writes/sec. No disk DB survives this.
Architecture:
- Driver → Location Ingestion (stateless fleet) → Redis Geo (spatial index) + Kafka (event stream)
- Kafka → WebSocket Gateway → Rider's app (live map update)
Key insight: Redis entries have a 15-second TTL. If a driver crashes, their entry auto-expires. No ghost drivers in matching results.
Step 3: Preventing Double-Booking
Two riders see the same driver as "nearest." Without protection → double booking.
Solution: Redis SET driver:{id}:lock {rideId} NX EX 20
-
NX= only set if not exists (atomic) -
EX 20= auto-expire in 20s (prevents deadlock) - Backstop: Postgres unique constraint on (driver_id, status=ACTIVE)
Deep Dive: Surge Pricing
Bad: Fixed prices. At peak demand, riders wait 10+ minutes.
Good: Simple 2x/3x multiplier.
Great: H3 hexagonal zones with real-time supply/demand signals:
- City divided into ~5km² hexagons
- Every 30s:
demand_score = requests / available_driversper zone - If > 1.5 → surge kicks in, capped at 3x
- Drivers see heat map → incentivized to relocate to high-demand zones
Full Design
This is a condensed version. The full breakdown (with Mermaid diagrams, sequence diagrams, ride state machine, 5 deep dives, technology choices table, and cost analysis) is here:
👉 Full Uber System Design on SystemCraft (free, no signup)
I've also written 15 other designs (Netflix, Instagram, Zomato, Google Docs, WhatsApp, etc.) in the same format at systemcraft.in.
What system would you like me to break down next? Drop it in the comments.