TRICKYwalkthrough
Ride Matching / Dispatch
A rider requests a ride in downtown San Francisco at 5:30 PM. There are 47 available drivers within 2 km.
The constraint: nearest distance is wrong. Driver A is 500m away but stuck in traffic facing the opposite direction with ETA 8 minutes.
“Which one should the system pick?”
Driver B is 900m away but heading toward the rider on a clear road with ETA 3 minutes. We chose a multi-factor ranking (not nearest-distance) because ETA, direction of travel, and driver quality all affect rider wait time.
Trade-off: we accepted higher matching latency (7ms for ranking vs 1ms for nearest-distance) in exchange for 40% lower average pickup time. The algorithm queries the rider's H3 cell plus k-ring neighbors, retrieves candidate drivers, computes ETA for each using a road graph with real-time traffic weights, and ranks by: ETA (50% weight), direction of travel (20%), driver rating (15%), and acceptance rate (15%).
The critical race condition: two riders 200m apart both see Driver B as optimal. Without protection, both dispatches reach Driver B simultaneously.
We solve this with optimistic locking on driver status: the first accept flips the driver from AVAILABLE to MATCHED in Redis with a CAS (Compare-And-Swap) operation. The second request fails the CAS check and we re-dispatch to the next candidate within 500ms.
Uber's DISCO system processes 11.6 matches per second average, peaking at 35/sec during rush hour.