Uber System Design

Design a ride-sharing platform like Uber that connects riders who need a trip with nearby drivers who can accept it in real time. In production this system lives or dies on three paths: a low-latency match when the rider taps "Request," a continuous location stream so ETAs stay believable on the map, and a server-owned ride state machine so neither side is guessing whether the trip is accepted, en route, or completed. Naive designs scan every driver in the city on each request or store locations only in a relational DB—both fail the moment Friday-night demand spikes.

You should support ride requests with pickup and dropoff, matching to nearby available drivers, live tracking during the trip, fare calculation (distance, time, and surge), payment settlement after completion, and two-sided ratings. Be ready to explain your geospatial index and how you query drivers within a radius in seconds, how you ingest 250K+ location updates per second without blocking matching, how you prevent double-assignment when two drivers tap Accept, and how surge multipliers are computed and applied. Matching latency, stale GPS handling, and what the rider sees when no drivers are nearby are all fair game—state your tradeoffs explicitly.