Design Uber: ride-sharing

Step 1

Requirements: functional and non-functional

The functional core:

• Drivers stream location continuously while online.
• Rider requests a ride; the system finds nearby available drivers.
• Match and dispatch one driver, exactly one, to the rider.
• Track the trip in real time until it completes.

Out of scope for the core answer (say it): pricing/surge, payments, routing/ETA internals, ratings. That is the right call for a 45-minute interview. But a real ride touches all of them, so in Step 9 we zoom out and design the whole ride-sharing platform those pieces belong to.

The non-functional shape:

Two facts drive everything: an enormous stream of ephemeral location updates, and a latency-critical "who is near me" query on top of it. A slightly stale driver dot is fine; dispatching the same driver to two riders is not.

Maps to S2 (requirements) and S1 (consistency vs availability, split by data type).

Step 2

Estimation: the numbers that bound the design

Maps to S2 (capacity estimation).

Step 3

API: the few operations

The location report is the hot, lossy write; the ride request is the rare, important one (idempotent, so a retry does not request two cars). Live trip tracking rides a persistent connection, like the messaging design.

Maps to S5 (API design): idempotent request, a firehose write, a persistent channel. See the API cheat sheet.

Step 4

Data model and store choices

Driver(id PK, status=online|on_trip|offline, current_cell)
DriverLocation[driver_id] -> {lat, lng, ts}        current only, overwritten
GeoIndex[cell_id] -> set of driver_ids             the spatial index
Trip(id PK, rider_id, driver_id, state, started_at)
Rider(id PK, ...)

stores
  Location + geo index .. 1M writes/sec, ephemeral, read by proximity   -> in-memory (Redis), sharded by geo cell
  Trip ................... must be correct + durable, state machine      -> relational / strongly-consistent
  Driver / rider profiles  ordinary lookups                              -> relational

Maps to S3 (store from access patterns) and S4 (shard the index by geography). See the data-stores cheat sheet.

Step 5

High-level architecture

Two flows over one index. The location ingest service takes the driver firehose and overwrites each driver's cell in the in-memory geo index. The matching service takes a ride request, queries the geo index for nearby drivers, picks one, writes a trip, and dispatches the offer to that driver. Separating the lossy write path from the careful match path is the whole shape.

Maps to S7 (architectural styles) and S4 (geo-sharded index).

Step 6

Deep dive A: geospatial indexing

The core technique. "Find drivers within 2km" is impossibly slow as a scan over millions of rows, so you carve the world into cells and index drivers by cell. A proximity query then touches only the rider's cell and its neighbors.

approaches (all the same idea: discretise the map)
  geohash   .. encode lat/lng to a string; shared prefix = nearby
  S2 / H3   .. hierarchical cells over a sphere (Google S2, Uber H3)
  quadtree  .. recursively split dense areas into smaller cells

query "drivers within radius of rider"
  1. compute the rider's cell
  2. gather that cell + its 8 neighbors (covers the radius)
  3. read the driver sets from those cells (small, in-memory)
  4. fine-filter by exact distance, sort by ETA

write "driver moved"
  cell changed?  remove from old cell set, add to new cell set
  same cell?     just update the stored point

Maps to S4 (partitioning by a key, here a spatial one) and S1 (space vs time).

Step 6 · continued

Deep dive B: the location firehose

A million-plus writes per second of data that is obsolete in seconds. The trick is to treat it as disposable and keep it in memory, sharded so no single node sees the whole planet.

ingest a ping
  - tiny payload {driver_id, lat, lng, ts}, fire-and-forget (UDP-ish)
  - route to the shard that owns the driver's region
  - OVERWRITE current location; do not append, do not persist to disk
  - if the cell changed, update the GeoIndex set membership

sharding
  - partition the in-memory index by geography (region -> shard)
  - a city's load stays on its shard; the planet never hits one node
  - replicate each shard for failover; losing one loses a few seconds
    of "current location" that the next ping refills

Maps to S4 (sharding the write path) and S9 (a lost ping self-heals; design for it).

Step 6 · continued

Deep dive C: matching without double-dispatch

Selecting a driver is easy; making sure one driver is not offered to two riders at once is the real work. This is a concurrency problem, not a geo one.

match
  1. candidates = geo query (nearby + status=online)
  2. rank by ETA / fairness / acceptance likelihood
  3. OFFER to the best driver, with a short timeout

the race: two riders, one nearby driver
  - claim the driver atomically before offering:
      SET driver:status online -> offering   (compare-and-set)
  - only the request that wins the CAS may offer that driver
  - on accept  -> on_trip;  on decline/timeout -> back to online,
    offer the next candidate
  => a driver can be in exactly one active offer at a time

Maps to S6 (idempotency and atomic claims) and S9 (fail closed on the dispatch).

Step 7

Reliability & failure design

The location path is deliberately the lossy, fail-open side; the match and trip path is the careful, fail-closed side. Regions are bulkheaded: each city is its own shard, so a surge or outage in one does not drain capacity from the rest. Calls are bounded with timeouts and breakers, and the driver offer has a short timeout so a non-responsive driver releases the claim quickly.

Maps to S9 (designing for failure): fail open on location, closed on dispatch. See the resilience cheat sheet.

Step 7 · continued

Observability & operability

• SLI / SLO: match latency (request to driver assigned) under target, say 99% within a few seconds; and the match success rate (requests that find a driver).
• Location freshness: ingest lag, the age of the positions the matcher is using. A naive design never measures this and matches on stale data.
• Per-region health: hotspots, shard load, supply/demand imbalance by city. Regional, because the system is sharded regionally.
• The three pillars: metrics for match latency and ingest lag, traces across ingest and matching, structured logs keyed by trip id.
• Alert on pain and burn: page on match-latency budget burn and shard saturation, not raw CPU.

Maps to S10 (observability). See the observability cheat sheet.

Step 8

Trade-offs along the six core axes

The whole design is one question answered fast and one answered safely: where are the nearby drivers (in-memory cells, eventually consistent), and is this driver claimable right now (atomic, fail closed). Say that and the boxes follow.

Maps to S1 (the six core trade-offs) and S12 (present and defend).

Step 9

Beyond the core: the whole ride-sharing platform

Steps 1–8 answered the interview: match a rider to a nearby driver. But a real Uber ride is wrapped in a dozen more subsystems. Before you request you want to see a price and an ETA; you have to pay at the end and the driver has to get paid; both sides had to be onboarded and trusted; and every event has to feed analytics, ML and safety. Same method, applied per subsystem. Here is the full platform, grouped by the four jobs it does: serve demand, manage supply, run the marketplace (price/ETA/money/trust), and the platform backbone underneath.

                         RIDER APP                         DRIVER APP
                             |                                  |
                 +-----------+----------------- EDGE -----------+-----------+
                 |     API gateway  ·  auth / identity  ·  rate-limit  ·  TLS     |
                 +-----------+----------------+---------------+-----------+
                             |                |               |
   === DEMAND SIDE ======== | ==== CORE ===== | ============= | == SUPPLY SIDE ===
   |  Trip request          |   Matching &    |   Dispatch    |  Driver location   |
   |  Fare quote  <--------+ |   dispatch      |   offers &    |    firehose  (core)|
   |  ETA / route preview   |   (Steps 1-8)   |   trip WS     |  Driver onboarding |
   |  Live trip tracking(WS)|                 |               |  Earnings / quests |
   |________________________|_________________|_______________|____________________|
                             \                |                /
   === MARKETPLACE INTELLIGENCE ===  === MONEY ===        === TRUST & SAFETY ===
   |  Surge / dynamic pricing   |  Fare calc + ledger  |  Identity & bg checks   |
   |  ETA & road-graph models   |  Rider payments(PSP) |  Fraud / risk scoring   |
   |  Supply positioning        |  Driver payout wallet|  Two-sided ratings      |
   |  Experiment platform       |  Receipts / invoices |  SOS / incident / support|
   |____________________________|______________________|__________________________|
                             |                |                |
   ############################ PLATFORM & DATA BACKBONE ###########################
     Event bus (Kafka)   ·   Maps/geo (H3, geocoding, road graph)   ·   Notifications
     Data lake + stream/batch   ·   ML feature store & serving   ·   Config / flags
     Service mesh   ·   Observability (metrics · traces · logs)
   ################################################################################

Maps to S7 (decompose a platform into services) and S8 (an event backbone decouples the producers from the dozen consumers).

Step 9 · module inventory

Every subsystem, one line each

Each module gets the same treatment as the core: what it does, where its data lives, and the one design call that defines it.

A · Demand side (rider-facing)

B · Supply side (driver-facing)

C · Marketplace: price · ETA · money · trust

D · Platform & data backbone (used by everything above)

Maps to S3 (a store per access pattern), S4 (shard each subsystem on its own key) and S8 (event-driven decoupling).

Step 9 · deep dive

The four that reward depth

Maps to S1 (consistency split by data type, again) and S11 (ML/data as first-class subsystems).

Step 9 · the through-line

One consistency map for the whole platform

Zoom all the way out and the entire platform sorts onto the same axis you drew for the core: what can be stale and lossy, versus what must be exact and durable.

That is the staff-level move: not a bigger box diagram, but one organising principle that tells you, for any new feature, which side of the line it belongs on. Rides are eventually consistent and fail open; money and identity are strongly consistent and fail closed; everything else hangs off the event bus.

Maps to S1 (the six axes) and S12 (present the platform as one idea, not fifteen boxes).