Problem Statement: A Real-Time Geospatial Marketplace
Frames ride-hailing as a stateful, latency-critical, two-sided marketplace rather than a request-response API.
Problem statement
Design a ride-hailing platform that connects riders with nearby drivers in real time. The product must let a rider request a ride and see an upfront fare and ETA, match them with an available driver within seconds, stream both parties' live locations during pickup and trip, compute dynamic pricing when demand outruns supply, process payment at drop-off, and support ratings, cancellations, and dispute recovery.
This is not a CRUD system. A marketplace is a continuously moving optimization problem: supply (drivers) and demand (riders) are distributed over a city, both move, and the platform must repeatedly re-solve assignment under a hard latency budget. Uber describes the dispatch core as a batched optimization that runs roughly every two seconds over city-scale cells, pairing pending riders with idle drivers to maximize global efficiency rather than greedily serving the earliest request.
Why this problem is distinctive
Three properties separate ride-hailing from ordinary backend design. First, the working set is geographic and hot: almost every interesting query is "drivers within N kilometers of this point, ranked by arrival time," executed millions of times per minute. Second, state freshness decays in seconds: a driver position from ten seconds ago is already a prediction, not a fact. Third, correctness is split by dataset: location may be eventually consistent, but a trip assignment is an exclusive lease — two riders can never own the same driver at the same instant, and a payment ledger must never double-charge.
Public operating baseline
Uber's 2024 filings report 11.2 billion trips for the year — about 30.7 million trips per day — 171 million monthly active platform consumers, and more than 8 million drivers and couriers earning on the platform. These are real published figures and establish that the category operates at genuine planetary scale. Lyft, Grab, DiDi, and Bolt run comparable marketplaces with regionally concentrated load. Everything else in this answer — QPS, storage, latency targets — is either attributed to a named engineering source or explicitly labeled as a design assumption.
The four architectural planes
- Edge plane: rider and driver mobile apps, GPS sampling, connectivity, offline behavior.
- Fulfillment plane: request intake, matching/dispatch, ETA, trip state machine, cancellation.
- Market plane: pricing, surge, incentives, payments, fraud, ratings.
- Data plane: location streams, trip facts, analytics, ML feature pipelines.
A strong interview answer keeps these planes separate: pricing failures must not block location tracking, and a matching outage must degrade to nearest-driver fallback rather than taking down the whole platform.
Key Highlights
- •Ride-hailing is a continuously moving two-sided assignment problem, not a request-response API.
- •Uber reported 11.2B trips in 2024 (~30.7M/day) and 171M monthly active platform consumers in its filings.
- •Correctness is dataset-specific: AP for location freshness, CP-style single writer for trip ownership and payments.
- •The dispatch core runs batched optimization every ~2 seconds over city cells (Uber's published DISCO approach).
- •Four planes: edge, fulfillment, market, data — each degrades independently.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "Let me separate the business workflow from the real-time location problem before choosing any technology."
- "The interesting constraint here is freshness in seconds and exclusivity of assignment, not raw request throughput."