← Lessons

quiz vs the machine

Platinum1800

System Design

Design a Ride Sharing Backend

Match riders to nearby drivers using geospatial indexing and live location.

7 min read · advanced · beat Platinum to climb

Requirements

  • Match a rider to a nearby available driver quickly.
  • Track live driver locations as they move.
  • Handle surges in dense areas.

High level design

Drivers stream location updates that feed a geospatial index, and a matching service queries that index when a rider requests a trip.

  • Location ingestion: drivers send periodic updates to a service that writes to an in memory geo index.
  • Geo index: a grid or geohash partitions the map so nearby drivers are found by cell lookup.
  • Matching: on a request the service queries nearby cells, ranks candidates, and dispatches an offer.

Bottlenecks

  • Update volume: many drivers updating constantly is heavy, so batch updates and keep the index in memory.
  • Hot cells: dense city centers overload single cells, so subdivide cells dynamically by demand.
  • Stale locations: a driver who stops reporting must expire, so age out entries that go quiet.

Once matched, a trip service tracks state from accepted to completed and handles cancellations.

Key idea

A ride sharing backend keeps a live geospatial index of drivers so a rider request becomes a fast nearby cell query followed by ranking and dispatch.

Check yourself

Answer to earn rating on the learn ladder.

1. Why use a geohash or grid index for driver locations?

2. How are dense city centers handled in the geo index?