SDE Path

Real-time matching & geo

Design Uber

Hard

Hand a rider the nearest free car in seconds — while millions of drivers rewrite the map with a GPS ping every few seconds.

Uber is a real-time, two-sided marketplace: a rider requests a car and the system must hand them the nearest available driver within seconds. What makes it a hard system-design problem isn't storing trips — it's the live geospatial index.

Two forces collide:

  • Location ingest is a write firehose — millions of drivers stream their GPS position every few seconds, so the index of "who is where" is being rewritten constantly.
  • Matching is latency-critical and read-heavy — riders fire "find nearby drivers" queries against that same moving index and expect a match almost instantly.

The whole design is about building a spatial index that is cheap to update and cheap to query at massive scale, then matching two sides over it without ever dispatching one driver to two riders. This is the canonical "real-time matching over live geo data" interview.

Start by scoping. The interviewer wants to see you separate the location-ingest path (millions of drivers streaming GPS) from the query + matching path (riders finding and getting a nearby car) early — that split, plus the live geo-index, drives every later decision. Keep the core to four verbs: drivers ping location, a rider requests a ride, the system matches the nearest available driver, and both track the trip live. Fare/surge and history are secondary layers over that spine.

Functional

  • Drivers stream location continuously; the system keeps a live, queryable view of every available car's position.
  • Rider requests a ride (pickup + destination); the system finds and matches the nearest available driver.Riders also see nearby cars on the map before requesting; the map view is served from the same live geo-index.
  • Dispatch the match: offer the ride, driver accepts/declines, both are notified in real time — with no double-dispatch.
  • Live trip tracking — the rider watches the driver approach with a continuously updated ETA.Fare (base + distance + time) and a demand-based surge multiplier are computed over the trip; itemized pricing and trip history are secondary CRUD over this spine.

Non-functional

  • Location-ingest throughput — sustain >1M location writes/s at peak (5M drivers pinging every ~4s).
  • Dispatch latency — a rider receives a matched driver within < 5s end to end; a nearby-driver query returns in < 200 ms p99.
  • Location freshness — a driver's known position is at most ~4–5 s stale (about one ping interval).
  • No double-dispatch — a driver is matched to at most one rider at a time (strong consistency on driver status).
  • High availability — target 99.99% for the marketplace; a single city/region outage must not cascade globally.

Out of scope

  • Payments & fraud internals
  • Trip-history browsing & receipts
  • Driver onboarding / background checks
  • Maps & routing engine internals (assume a Maps/ETA service)

Check yourself· 3 questions

Question 1

Which capability is the true crux that shapes the whole system?

Question 2

Why separate the location-ingest path from the matching/query path early?

Question 3

"A driver is matched to at most one rider at a time." This requirement is closest to…