Design Uber
PremiumProduct architectureHard
- Ride matching
- Geospatial index
- Driver location tracking
Quick answer
This product architecture interview question asks you to design Uber. Aim for a design that meets its requirements at the stated scale, then explain its main components, data flow and trade-offs. Interviewers want to see how you scope the problem, size it and defend each choice.
The problem
Design Uber, a ride-hailing app that matches a rider with a nearby driver in seconds, shows the driver's live location and charges the fare when the trip ends. The hard parts are a location index that absorbs hundreds of thousands of writes per second and a matching step that never gives one driver two trips.
Two apps share one backend: the rider app and the driver app. You own the backend API, the trip lifecycle, the matching flow and the live channels to both apps.
What must the system do?
- Request and match: A rider sets pickup and drop-off, sees an upfront fare and requests a ride; the system offers it to nearby drivers until one accepts.
- Live tracking: During pickup and the trip, the rider sees the driver's position and ETA update every few seconds.
How well must it do it?
- No double assignment: A driver is never on two trips at once, and one ride request never ends up matched to two drivers.
- Fast matching: In busy areas, 95% of requests reach a driver's phone as an offer within 5 seconds; after 60 seconds with no match, tell the rider.
What scale should you design for?
Use these numbers in your estimates.
The scale numbers unlock with this questionUnlock
Key concepts
- Ride matching
- Geospatial index
- Driver location tracking
- WebSocket
- Trip state machine
- Idempotent payments
How you’ll practise
- Requirements
- Core entities
- API design
- Client and server flow
- Scale and edge cases
- Wrap-up
Lala, personalized to you, gives a hint when you ask and reviews your design when you are ready.
What do interviewers look for?
In any product architecture design round.
- Clarifies the requirements before drawing anything
- Uses a few numbers that actually change the design
- Draws a clear path from the client to storage
- Picks storage and caching with reasons, not by habit
- Explains what breaks first under load and how to fix it
- States trade-offs openly instead of claiming a perfect design
Questions people ask about this interview question
- Which design type is this question?
- It is a product architecture question. You design Uber and explain your choices the way you would in an interview.
- Is this question asked at entry level?
- It is marked Hard. It suits engineers preparing for senior interviews, where you are expected to drive the discussion and go deep on trade-offs.
- What should I cover first?
- Start with the requirements: what the system must do, how well it must do it and which numbers change the design. Agree on scope with the interviewer before you design anything.
- Can I practise it for free?
- It is a premium question. Sign up and unlock it once for 10 credits; it then stays unlocked. When you finish, Lala, your personalized AI mentor, can review your design for 30 credits.
Related questions
Updated · Written by the SevyDevy team