Matching riders and drivers across a busy city
Design a Ride-Sharing Service (Uber-style), from a blank page
This is how the interview actually runs: one prompt, and you decide what to cover and in what order. Write each section, then compare it with a reference design and see what you left out.
A 45-minute round. You drive; nothing prompts you.
The prompt
A ride-hailing app lets a rider request a pickup and destination. The service finds nearby available drivers, estimates pickup time, offers the trip, and tracks the ride until it ends. A driver can be offered only one trip at a time, and a rider must never see two drivers accept the same request.
In one large city, about 60,000 drivers are online at peak. Each app sends a location update every 3 seconds while available. The marketplace handles about 2,000 ride requests a minute on average, with short 5× peaks after events and during bad weather. A candidate offer should reach a driver in about a second. A stale map pin is worse than no pin: drivers who have not reported in ten seconds are not eligible for a new match.
The design below is a practice problem, not a description of Uber's private architecture. Uber has publicly described H3, a hierarchical hexagonal grid used for marketplace analysis and dispatch-related decisions; the exercise asks you to choose and defend a design under its own assumptions.
What the interviewer would tell you if you asked
- 60,000 online drivers in the city, sending one location update every three seconds while available.
- 2,000 ride requests a minute on average; peaks reach five times the average for several minutes.
- The first offer should be sent within about one second; pickup estimates should use road travel time.
- Start with one city and one primary database; the system may later expand to many cities and regions.
- A driver can take one active ride at a time, and available drivers opt in to location sharing.
- Location is a short-lived hint for matching, not the durable record of a completed trip.
- A routing service can estimate pickup time for a small candidate set, but calling it for every driver is too slow and costly.
- Push delivery is at least once in practice: messages can be delayed, retried, or arrive out of order.
01
about 5 minWhat does the system have to do, and how well? List the functional requirements, then the non-functional ones (latency, availability, consistency, scale), and the questions you would ask the interviewer.
02
about 5 minTurn the volumes into the numbers that drive the design: requests per second at peak, storage, bandwidth, and anything else that decides whether one machine is enough.
03
about 10 minName the components and what each one is responsible for. Then trace the main request through them, and say where the durable state lives.
04
about 15 minPick the hardest decisions in this design and make them: what you chose, what you rejected, and which constraint decided it.
05
about 10 minWhat breaks? Walk through crashes, duplicates, slow dependencies and overload, and what the design does in each. Then: what changes at ten times the load, or with a new requirement?
Write something in at least 3 sections first. Gaps are fine; the comparison shows what they cost.