Question 1174

Nearest Driver Wins

Design the ride matching backbone for a ride hailing service: drivers stream their location while online, a rider requests a ride, the system picks a nearby driver, and both sides watch the trip until dropoff.

Requirements

Functional:

  • Drivers publish a location fix every few seconds while online.
  • A rider requests a ride from a pickup point and gets either a matched driver or a clear "no supply" answer.
  • The chosen driver is offered the trip and can accept or decline; a decline or a timeout re-matches the rider.
  • Rider and driver both see live position and an updated arrival estimate until the trip ends.
  • Completed trips are durable: route, timestamps, and the inputs a fare would be computed from.

Non-functional:

  • p95 from ride request to driver offer under 2 seconds, p99 under 5.
  • A driver is never on two active trips at once.
  • The rider's map is never more than 5 seconds stale.
  • Losing an occasional location sample is acceptable; losing trip state is not.

Scale

  • 8M rider DAU, 900k drivers online at peak, 25M trips per day.
  • Location ingest: 900k drivers on a 4 second interval, about 225k writes/sec, 120 byte payloads.
  • Ride requests: about 290/sec average, 900/sec at peak.
  • 400k concurrent trips at peak, each pushing one position update per second to the rider.
  • Trip records about 2 KB each, so roughly 50 GB/day of durable trip data.

Out of scope

Payments and driver payouts, surge pricing, fraud review, driver onboarding, and the map routing engine itself (treat routing and travel time as an external service you call).