Uber / Lyft — Ride Dispatch

Design Uber. Riders request; nearby driver assigned; live tracking; dynamic pricing; payments. ~10M rides/day; dispatch latency < 3s; ETA accuracy ±3 min p90.

Time budget: 45 min whiteboard. Draw architecture, estimate numbers, discuss tradeoffs.

Hint 1

Dispatch is not nearest-driver. It's a batched (1–2s window) assignment problem optimizing multiple objectives.

Hint 2

Geospatial index (H3 / geohash / quadtree) for 'nearby drivers' queries at high QPS.

Hint 3

ETA + routing is ML, not distance-over-speed. Features include time-of-day, traffic, driver profile, historical data.

• +1 BoE: ~116 rides/sec avg, ~300K active drivers, ~150K location-pings/sec baseline
• +2 Dispatch as batched (~2s window) assignment problem; Hungarian algorithm over (driver, ride) scores
• +2 H3 hexagonal cells for geo-index; ring queries for nearby drivers; Redis GEO as implementation
• +1 Saga pattern for trip lifecycle: request → assign → pickup → drop → pay — each idempotent step
• +1 ML-based ETA: GBDT model with distance, traffic, time-of-day, driver speed; not simple distance/speed
• +1 Surge pricing: real-time feature of demand/supply ratio per region; enforced at quote time, locked for N min
• +1 Discusses how driver location pings are downsampled (every 4s, not every 100ms) + stored tiered
• +1 Failure handling: dispatch fallback to nearest-driver on ML outage; payment held on auth before assign

Self-score: tally the points you would have mentioned unprompted. 7+ is interview-ready on this problem.

• Proposes nearest-driver-wins greedy assignment (doesn't discuss batching)
• SQL table for driver locations with no geospatial index
• ETA is 'distance / avg_speed' with no ML
• 2-phase commit across driver / rider / payment (should be saga)
• Ignores surge pricing complexity