Design Uber
Problem Statement
Design the rider and driver client experience for a ride-hailing app: setting a destination, requesting a ride, watching a matched driver approach on a live map, riding, paying, and rating. The interesting work in this round sits in three places: the trip is a long-lived state machine that both clients must render truthfully, the driver client streams location under real battery and connectivity constraints, and the rider client has to make discrete position updates look continuous without lying about where the driver is.
This walkthrough follows the Product Architecture framework: requirements, data model, API design, high-level client architecture, and product trade-offs.
Everything below the API contract is out of scope here. The matching service, the geospatial index that finds nearby drivers, the routing engine, surge pricing, and service topology are all one-line hand-waves: "a matching service backed by a geospatial index picks the driver, and the endpoint returns a match." Your time goes into the trip state machine, the endpoints, the live channel, and what each client renders and stores.
The System Design round asks for the same product below the API line: geospatial indexing with quadtrees or S2 cells, matching at scale, sharding driver location writes, and dispatch consistency. See Uber for that version. The difference in focus is simple: System Design asks how the server finds a driver, Product Architecture asks what the two apps render, store, and send while that happens.
Common Aliases
- Design a ride-hailing app from the client perspective
- Design Lyft or a rideshare rider and driver app
- Design real-time trip tracking and the ride lifecycle
- Product architecture: live location and driver ETA on a map
Level Calibration
The material below is more than any one candidate delivers in 45 minutes, and how much of it you are expected to produce depends on your level.
| Level | What a complete answer looks like |
|---|---|
| Mid-level | Requirements, the data model, the five core endpoints, the trip state machine, and one deep dive carried to a conclusion. Roughly 80% breadth, 20% depth. |
| Senior | All of that, plus the cancel race and marker interpolation raised on your own and taken to a named rule rather than a mention. Roughly 60/40. |
| Staff+ | All of that, plus privacy as an API shape and the offline and clock story. Roughly 40/60, and the expectation is that you name these before anyone asks. |
The depth below is written at senior to staff. A mid-level reader should treat the deep dives as reference, not as a script to recite.