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

Shaswat Kumar — Fri, 26 Jun 2026 12:38:20 +0000

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_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.

DEV Community: Shaswat Kumar