System Design Interview
Ride hailing inspired by Uber's published designs: driver pings into an in-memory H3 geo index, ETA-ranked dispatch with sequential offers and atomic assignment, per-cell surge pricing from the location stream, trip events for notifications and payments, and per-trip GPS history. A teaching design.
See why writing every GPS ping to a database and matching with SQL falls over.
What was missing: Nothing yet.
Why that's risky: Drivers' pings (80K per second) overwhelm row updates, distance queries scan every driver, and two requests can grab the same driver.
What gets added: One server that stores each driver's latest location as a row and finds the nearest driver with a SQL distance query.
Trade-offs: Simple, but locations change far faster than a database row should.
Absorb GPS pings in memory and find nearby drivers by cell.
What was missing: Pings were database writes and matching was a table scan.
Why that's risky: The nearest driver by straight line may be across a river, and drivers can't decline.
What gets added: A location service that keeps every online driver in an in-memory index of hexagonal H3 cells, sharded by city, and a trip service that picks the nearest available driver from nearby cells; assigning a driver is a conditional update in the trip database.
Trade-offs: The index holds only the latest position, so a restart loses positions for a few seconds until the next pings.
Pick the driver who can actually arrive soonest, and let drivers accept.
What was missing: Matching used straight-line distance and assumed drivers would accept.
Why that's risky: Prices ignore demand, so at rush hour requests pile up with no drivers.
What gets added: A dispatch service that ranks nearby available drivers by ETA on the road graph with live speeds, offers the ride to one driver at a time through a push channel with a 15-second timeout, and assigns atomically on accept; the trip service owns the trip's state machine.
Trade-offs: Offering sequentially takes longer than broadcasting but never makes two drivers race for one ride.
Quote fares and balance supply and demand per neighbourhood.
What was missing: No fare quotes and no response to demand.
Why that's risky: Riders and drivers aren't notified of changes, and nobody is charged.
What gets added: A pricing service that quotes fares with the surge multiplier for the pickup cell, and a surge calculator that compares open requests with available drivers per cell every minute, fed by the location stream.
Trade-offs: Surge is per cell and per minute, so prices can differ across a street; smoothing limits sudden jumps.
Keep riders informed and charge correctly when the trip ends.
What was missing: No notifications and no payment.
Why that's risky: GPS traces aren't kept, so fare disputes and safety reviews have nothing to go on, and abuse isn't limited.
What gets added: A trip event stream feeding a notification worker (driver assigned, arriving, started, receipt) and a payment worker that charges the rider and records driver earnings when the trip completes.
Trade-offs: Charging after the trip means a small risk of failed payments, handled by retries and account holds.
Keep trip traces, block abuse, and watch matching quality.
What was missing: No trace history, no rate limits, no monitoring.
Why that's risky: Remaining risk is regional: each city's dispatch should fail over to another data centre.
What gets added: A location history writer storing GPS traces per trip, a rate limiter, and monitoring of time to match, offer acceptance, ETA error and ping lag.
Trade-offs: Traces are kept for a limited time for privacy.
Use soft-state location caches with TTLs and tolerate small staleness while updating positions frequently.
Apply rate limiting at the gateway and buffer non-critical events through queues with autoscaling workers.
Shard by city or region to keep hot ride data local and reduce cross-region latency.
Matching is latency-sensitive and benefits from isolated scaling and caching.
Caching nearby drivers reduces repeated database lookups for real-time location reads.
Event streams decouple real-time ride actions from downstream analytics and notifications.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own:
