Skip to content
Devgo

Uber dispatch

Real-time matching of riders to nearby drivers

Uber matches riders to the nearest available drivers in seconds. The core is a geospatial of driver locations updated constantly, a dispatch service that finds nearby cars, and a stateful trip manager. Reads dominate; location updates are high-frequency.

Product constraints

  • Match in seconds; location data is stale within seconds.
  • Drivers move constantly; high-frequency location updates.
  • Geospatial 'find nearby' is the hot query.
  • Trip state must be consistent between rider, driver, and the system.

High-level diagram

Uber dispatch architectureA block diagram of the Uber dispatch system's main components and request flow.DriverGPSGeo indexgeohashRiderDispatchMatchTrip statesharded DB
Illustrative block diagram of Uber dispatch. Not to scale; see the request path below for flow.

Request path

  1. Driver location. Drivers stream GPS updates; a geospatial (geohash/grid) tracks who is where and available.
  2. Rider request. Rider requests a ride; dispatch queries the geospatial for nearby available drivers.
  3. Match. Offers sent to the nearest drivers; first to accept wins; a trip is created and state is pinned.
  4. Trip. Trip state machine (requested→enroute→pickup→ongoing→complete) managed by a stateful service; both parties see updates via realtime channels.

Data model

Driver location/availability in a geospatial store (geohash or GEO). Trip state in a strongly-consistent store (sharded DB). The dispatch is rebuilt/updated continuously from driver pings.

Storage / cache / queue choices

Storage

Geospatial ( GEO / geohash) for nearby drivers; sharded DB for trip records.

Cache

for driver location and availability hot state.

Queue

for location events and analytics; not the dispatch path (too latency-sensitive).

Scaling levers

  • Geospatial makes 'find nearby' sub-linear instead of scanning all drivers.
  • Shard by region/city; dispatch is local.
  • Stateful trip service avoids DB round trips for hot state.
  • High-frequency location updates via a lightweight protocol (not per ping).

Copy vs skip (for a smaller team)

Copy
  • Use a geospatial index for 'find nearby' (geohash/Redis GEO).
  • Shard dispatch by region; keep it local.
  • Stateful trip management for hot state.
  • Separate the hot location path from trip persistence.
Skip
  • Scanning all drivers to find nearby (won't scale).
  • Global dispatch (shard by region).
  • Persisting every GPS ping to the DB (use a hot store).

, , ,

Sources