sydepsystem design atlas

Ride Matching (Uber-style)

Match riders to nearby drivers using live location and a geo index.

AdvancedCommerce
Rider AppClientDriver AppClientAPI GatewayNetworkingLocation StreamMessagingGeospatial IndexStorageMatching ServiceComputeTrip StoreStorage

Driver locations stream continuously into a geospatial index; a matching service queries nearby available drivers for each ride request and coordinates the offer/accept handshake in real time.

When to use it

  • Matching depends on real-time proximity between two moving populations
  • Location updates are frequent and must be queryable with low latency

Trade-offs

  • Geospatial index must handle very high write throughput from constantly moving drivers
  • Matching fairness and driver-side accept/reject timing need careful tuning to avoid poor UX

Components used

Mobile AppAPI GatewayEvent StreamCacheManaged App ServiceDocument Database

How it works

  • Driver apps stream location updates continuously into a geospatial index that supports fast 'who is near this point' queries.
  • A ride request queries that index for nearby available drivers, then a matching service ranks candidates by ETA, rating and routing before offering the trip.
  • Offers are time-boxed; a driver who does not accept within seconds releases the hold and the next candidate is offered.

Used in the wild

  • Ride hailing and taxi dispatch.
  • On-demand courier and field-service assignment.
  • Any real-time supply/demand matching constrained by physical proximity.

Good to know

  • Location updates dwarf ride requests in volume — often by three or four orders of magnitude — so the write path, not the matching logic, dominates the architecture.
  • Geohashing and S2 cells reduce proximity search to a prefix or range scan. Uber's H3 library uses hexagons specifically because hexagon centres are equidistant from all neighbours, unlike squares.