Question 13 · Track 4 · Find it
Design a ride-sharing service
Every driver is writing their position to you, forever.
Find it. 4 clarifying questions to ask first, the answer in 4 moves, the follow-up that catches a memorised answer and 2 supporting topics to watch or read.
Short answer live
What it is really testing
Whether you separate a high-frequency location stream from the transactional trip record.
Ask these first
Before a single box goes on the board. The answers change the design, which is the point of asking out loud.
- How many drivers online at peak, and how often do they report position?
- How fast must a rider be matched?
- What happens if two riders request the same driver?
- Do we need trip history, and for how long?
The answer, in 4 moves
In this order. Each move earns the next one — say them out loud rather than drawing all four and narrating afterwards.
- 1Divide the map into cells so "nearby" is a lookup, not a scan of every driver.
- 2One matching service ranks candidates by ETA and offers the ride on a short-lived lease.
- 3The location stream’s destination is the geospatial INDEX, not the trip database.
- 4Model the trip as an explicit state machine: requested → matched → started → ended.
The trap
The follow-up that separates a rehearsed answer from a real one.
Writing every GPS ping into the trip table is what kills it. Positions are a stream with a short useful life; the trip is a transaction. Mixing them puts your durable data behind a firehose.
Watch or read
The pieces of this answer, each covered on its own. Take them whichever way suits you, then give the whole answer without looking.
Proximity search and spatial indexes
You tap "restaurants near me" and get an answer in 50 ms — out of ten million rows the database never measured the distance to. That's spatial indexing: stop indexing points, start indexing space. Here's the grid trick, the 3×3 neighbor lookup, the cell-size trade-off with both extremes, why fixed grids go lopsided, and how the exact same prune-then-measure idea powers vector search for LLMs.
Pub/sub vs API calls
A user signs up, and email, push, and analytics all need to know. Do you call each service yourself, or publish one event and walk away? Here's Pub/Sub vs direct API calls — event-driven async messaging vs synchronous request/response — with a clear rule for which one to reach for.
Part of System Design Interviews, Answered Out Loud. The fundamentals underneath it are the free CS course.