Uber Ride Hailing – System Design Interview Preparation

Practice designing a ride-hailing platform like Uber. Cover driver matching, geospatial indexing, surge pricing, and real-time tracking.

This is a full mock interview round, not a written solution to read through. The AI interviewer poses the Uber design problem, pushes back on your choices, and asks the follow-up questions a real interviewer would: how the system behaves as traffic grows, where the bottlenecks move, which consistency guarantees you are trading away, and what happens when a component fails. You get structured feedback and a score on requirement gathering, high level architecture, data modelling, scalability and communication at the end of every attempt.

Designing Uber is a recurring question in High Level Design (HLD) rounds at Google, Amazon, Meta, Microsoft, Netflix and Uber, and at high-growth product companies hiring SDE-2 and above. Working through it out loud - repeatedly, under time pressure - is what separates candidates who know the components from candidates who can defend a design.

What this question is really testing

Geospatial indexing over moving points, and a matching decision that must be made in under a second with stale location data.

Scale to establish before drawing anything

5M drivers sending a location every 4 seconds - over 1M location writes a second, which is the dominant write load.
Matching must complete in about a second; a proximity query over a city must return in milliseconds.
Trip records are small and low-volume by comparison - thousands a second, not millions.

Core components

Location ingestion – High-throughput writes of driver positions. Last-write-wins; history is a separate, asynchronous concern.
Geospatial index – Geohash, quadtree or H3 cells over available drivers. Name one and say how it is updated.
Matching service – Finds candidates in the rider's cell and its neighbours, ranks them, and offers the trip.
Trip service – The trip state machine: requested, accepted, arrived, started, completed.
Pricing service – Base fare composed with a surge multiplier derived from supply and demand per cell.

Trade-offs to defend

Cell size in the spatial index – Small cells mean precise queries and many neighbour lookups; large cells mean one lookup and more candidates to filter. This is the tuning knob the question is about.
Stale locations – A 4-second-old position is wrong by 50 metres on a highway. Matching has to tolerate that rather than pretend it is exact.
Surge granularity – Per-cell surge is responsive and gives riders a different price across the street. Smoothing costs responsiveness.

Follow-up questions to expect

Walk through a proximity query: which cells do you read, and how many drivers do you rank?
A driver accepts and immediately loses signal. What is the timeout, and what does the rider see?
A concert ends and 10,000 people request rides from one cell in two minutes. What breaks first?