Ride Hailing — Matching Riders to Drivers
hardOpen designCommonly asked~45 minHLD roundBar raiserSenior / SDE-3UberGoogleAmazonSwiggyFlipkartStorage & Data ModellingSharding & PartitioningQueues & Async
The question, as asked
“Design the part of Uber or Ola that matches a rider to a nearby driver.”
Scope it before you design it
The prompt is vague on purpose. These are the clarifying questions a strong candidate asks first — answer them out loud before you touch the architecture.
- Matching only, or the whole product? Pricing, payments, routing and ETAs are each their own system — get the interviewer to bound it or you'll design four systems badly.
- How many drivers are online in a city at peak, and how often do they report location? Those two numbers multiply into your entire write load.
- Is matching immediate, or is there a batching window? Batching a few seconds of requests produces far better matches and changes the algorithm completely.
- What does 'nearby' mean — straight-line distance or road distance? Straight-line is cheap and wrong at the edges; road distance needs a routing engine on the hot path.
- Can a driver receive two offers at once? This is the double-booking question in disguise, and the answer decides whether you need locking.
- Pooled rides, or one rider per trip? Pooling turns matching into a much harder combinatorial problem — confirm it's out of scope.
- How fresh must driver locations be? Five seconds stale is fine for matching; for showing a car moving on the rider's map it isn't.
Your answer, first
Commit something before anything unlocks. Saved on this device as you go.
0 charactersExpand for room to draw
Framework hint
Sketch or write your approach above first. The hint gives you the structure, not the answer.