How I'd Design Uber in a System Design Interview (Full Breakdown)

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):

1. Riders request a ride → get matched with nearest driver in <30s
2. Real-time location tracking — drivers send GPS every 3-5s
3. 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:

1. Rider taps "Request Ride" → hits API Gateway
2. Matching Service asks Redis Geo: "drivers within 3km of pickup"
3. Ranks by ETA (not raw distance — a driver 500m away in traffic is worse than 1.2km on a highway)
4. Locks the best driver with SET NX EX 20 (atomic distributed lock with 20s TTL)
5. 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_drivers per 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.