Design Uber: Ride Matching with Live Locations, No Double Booking

Four user-facing capabilities define the scope. Before committing, a rider enters a pickup point and destination and gets back a price and an estimated arrival time. When the rider confirms, the platform searches for an available driver close by. That driver receives an offer on their phone and chooses to accept or reject it.

After a successful match, both parties follow the journey on a live map from pickup to drop-off. Payments, ratings and scheduled rides all matter in a real product, but each is a substantial system on its own, so we set them aside. That keeps attention on location tracking and matching, which is where the interesting design decisions live.

Speed shapes the rider experience. Searching for nearby drivers should complete in under a second, and the full match, including the driver's decision, should land within about a minute. Consistency is non-negotiable: assigning one driver to two rides creates a broken experience for at least one rider and erodes trust in the platform.

The write load is unusual. Every online driver reports their position every few seconds whether or not they have a passenger, so location updates vastly outnumber everything else. Availability must hold during spikes like New Year's Eve or the end of a big match, when demand can jump to ten times normal, which is exactly when riders most need the service to work.

Assume around 2 million drivers online at peak, each sending a GPS update every 4 seconds. That works out to roughly 500,000 location writes per second. Rides are a much smaller stream: assuming 30 million trips per day gives only about 350 ride requests per second on average.

Now size the live state. Each driver's current position plus a little metadata is about 100 bytes, so the entire fleet's latest locations come to roughly 200 MB. That is small enough to sit comfortably in memory on a single node, with replicas for safety. The conclusion drives the architecture: the location firehose dominates the load, and because only the latest point matters for matching, the geo index should live in RAM rather than on disk.

Four entities carry the domain: Rider, Driver, Ride and Location. The Ride is the durable business object that must survive crashes and audits; Location is high-frequency, short-lived data that is overwritten constantly, so the two are stored in very different places.

Booking happens in two calls. POST /fare takes pickup and destination and returns a fare_id, price and ETA, which lets the server lock in a quote. POST /rides with that fare_id creates the ride in a MATCHING state. Drivers stream their position through POST /drivers/location with latitude, longitude and timestamp. Drivers advance a trip with PATCH /rides/{id}, passing an action such as accept, decline or arrive, and the server validates whether that transition is allowed from the current state.

Riders reach the backend through an API gateway that authenticates requests and routes them. The ride service owns quoting and ride creation, persisting every ride and its current status in Postgres. Separately, driver apps send GPS updates to a location service built to absorb hundreds of thousands of writes per second, and it overwrites each driver's entry in an in-memory geo index backed by Redis.

When a booking arrives, the ride service hands it to a matching service. Matching asks the geo index for available drivers near the pickup, picks the best candidate, and claims that driver through a short-lived lock in Redis before pushing an offer to their app. A yes from the driver finalises the assignment; otherwise the lock is dropped and the next candidate gets the offer. Keeping location ingestion and matching as separate services means a surge in pings never slows down ride creation.

A relational table with latitude and longitude indexes is the familiar starting point, but half a million updates per second would hammer it, and B-tree indexes handle two-dimensional proximity poorly. An in-memory quadtree subdivides dense areas into finer squares, which suits uneven city density, yet constant driver movement keeps forcing nodes to split and merge.

Fixed grid cells are the better fit. Geohash or H3 assigns every point to a cell ID, so an update is just moving a driver from one cell to another, and a search reads a handful of cells. Redis offers this out of the box: GEOADD stores points encoded as geohashes and GEOSEARCH returns those within a radius. With H3 hexagons, we query the rider's cell plus the surrounding ring, which catches a driver parked just over a boundary.

Only the latest position is held in memory. The complete trail of pings is published to Kafka and landed in cheap storage, where billing, fraud checks and analytics can use it without touching the hot path.

Matching starts by pulling the closest available drivers from the geo index and ranking them by estimated time to pickup instead of raw distance, since a driver across a river may be close as the crow flies but far by road. The top candidate is then claimed with SET NX on a Redis key and a 10-second TTL. When two ride requests race for the same driver, only one write succeeds and the loser moves on to its next candidate.

With the lock held, the offer is pushed to the driver's phone and the matcher waits up to ten seconds. An accept is committed to the rides database through a conditional write that checks the driver has no other active ride, so the database remains the final authority. A decline or silence releases the lock (or lets it expire) and the next driver is tried. Ride requests sit in a durable queue throughout, so if a matcher crashes, another instance picks up the work and any orphaned locks clear themselves after their TTL.

A ride follows a short, explicit lifecycle: REQUESTED, MATCHING, ASSIGNED, ARRIVED, IN_TRIP and COMPLETED, with CANCELLED reachable from the early stages. Writing these down prevents ambiguous situations like a ride being both cancelled and in progress.

Each transition is executed as UPDATE ... WHERE status = expected. If the current state is not what the caller assumed, the update affects zero rows and the request is rejected, which blocks illegal jumps and makes retries harmless. Timers push stuck rides forward: when several minutes pass without an acceptance, the status flips to NO_DRIVERS and the rider is informed. Every successful change emits an event, so notifications, billing and ETA updates react to the stream rather than polling Postgres. During the trip, the driver's pings are relayed to the rider over a WebSocket so the car glides across their map.

Frequent pings give accurate positions but cost bandwidth and battery; letting idle or parked drivers report less often cuts load without hurting matching. Holding the geo index in memory is fast but volatile, which is acceptable because every driver repopulates their position within seconds after a restart.

Pairing a Redis lock with a conditional database write gives speed in the common case while keeping Postgres as the source of truth if the cache misbehaves. Ranking by road-network ETA chooses better drivers than straight-line distance, at the cost of extra computation per request. In short: keep live positions in RAM, claim a driver before offering, and guard every status change with a conditional write.