Design ride hailing (Uber / Ola)

The live location of drivers is the most write-heavy data and the least durable: a driver's position 30 seconds ago is worthless. So keep it in memory and never write each ping to a disk-based database. Divide the map into cells. H3 (Uber's hexagonal grid) is a good choice because every hexagon has six equidistant neighbours, which makes 'search the ring around this cell' simple; geohash with neighbour lookups also works. At H3 resolution 8 a cell is about 0.7 km², and resolution 9 about 0.1 km². On each ping, the location service computes the cell; if it changed, it moves the driver from the old cell's set to the new one, and it always overwrites the driver's latest position. Shard by city, then by cell, so Bengaluru's load never affects Pune. A nearby query reads the pickup's cell and rings outward until it has enough candidates, then filters by status and vehicle type. Pings also go to Kafka for trails and analytics, decoupled from the index. Clients send every 4 s while active, less often when idle or stopped, and batch points after a network gap; the server discards out-of-order points older than the latest it has. Stale drivers drop out of the index via TTL.

Nearest by straight line is often wrong: a driver 500 m away across a flyover or a one-way road may be 8 minutes away. Rank candidates by road ETA from the routing engine (one-to-many matrix), then adjust for acceptance likelihood and fairness. Two dispatch styles exist. Greedy: match each request immediately to its best available driver; simple and fast. Batched: collect requests in a city zone for 1-2 seconds and solve an assignment problem across requests and drivers, minimising total pickup time; this gives better global results in busy areas, and Uber has described moving to batched matching. Mention both and choose batched for dense cities. Double assignment is the classic bug: two dispatch workers offering the same driver to two trips. Prevent it with an atomic lock per driver (Redis SET driver:X:offer trip_id NX PX 15000) and by making the accept a conditional update on the trip. The offer is a lease: if the driver does not answer before the TTL, the lock expires and the driver is free again. Keep offers sequential per driver but allow dispatch to prepare the next candidate while waiting, to cut matching time.

Trips move through states: MATCHING → DRIVER_ASSIGNED → DRIVER_ARRIVED → IN_PROGRESS → COMPLETED, with CANCELLED_BY_RIDER, CANCELLED_BY_DRIVER and NO_DRIVER_FOUND branches. Store trips in a strongly consistent database and make each transition a conditional write: UPDATE trips SET state = 'IN_PROGRESS', version = version + 1 WHERE trip_id = ? AND state = 'DRIVER_ARRIVED'. This settles races like a rider cancelling at the exact moment the driver accepts: only one update wins, and the loser gets a clear error that the app can show. Every transition emits an event (via an outbox, so the event and the state change commit together) for payments, notifications and analytics. Clients are not the source of truth: after a reconnect, the app calls GET /trips/{id} and redraws from server state. Partition the trips table by city or by trip_id; queries by rider or driver for history use secondary indexes or a separate read model. Cross-region: a trip lives in the region that serves its city, which keeps writes local and fits Indian data localisation preferences.

Drivers in Tier-2 and Tier-3 cities and riders in basements lose connectivity often. Use persistent connections (WebSocket or MQTT) for both apps, with heartbeats every 10-20 s and quick reconnect with jitter. The WebSocket gateway is stateful: it maps user_id to the connection on a specific node, stored in a shared registry (Redis), so the trip service can route a message to the right gateway node. For the rider's live map, subscribe the rider to the assigned driver's location topic; the gateway forwards updates at most every 2-4 s and the app interpolates movement between points so the car moves smoothly. If a driver goes silent for 30-60 s during a trip, do not cancel: mark the location as stale, keep the trip, and let the driver app buffer GPS points and upload them on reconnect, which also keeps the distance and fare correct. Use SMS or push as a fallback for critical events like 'driver arrived' and offers. Keep message payloads small (binary or compact JSON) because data costs and bandwidth matter for drivers.

Greedy is simpler and gives the fastest single match but makes poor global choices when demand is high. Batching over a 1-2 s window improves total pickup ETA and driver utilisation in dense areas at the cost of a small delay and more complex code. Use greedy in sparse areas and batched in dense zones.

Redis GEO (geohash-based sorted sets) is quick to build with and good up to large scale with sharding by city. A custom service holding an H3 grid in memory gives full control over ring searches, filtering and sharding, which large players choose. Start with Redis, partitioned by city, and move when needed.

Upfront fares give riders certainty and are easier to dispute, but the company carries the risk of traffic and route changes. Metered fares are fair to drivers but uncertain for riders. Most apps now quote upfront and only recompute on clear changes (destination change, long waits).

After a cricket match at Chinnaswamy, tens of thousands of requests come from a few cells. One shard holds those cells, and dispatch for that zone becomes hot. Split hot cells to a finer H3 resolution, run batched matching per zone, queue requests with an honest wait estimate, and rely on surge to balance demand.

Each dispatch needs a one-to-many ETA matrix; at 10x requests this dominates cost. Pre-filter candidates by straight-line distance, cap the matrix size (say 20), cache ETAs between cells for a minute, and use a fast approximate ETA model for ranking with exact routing only for the final pick.

New matches in that city stop until a replica takes over; drivers reconnect and re-send their location, so the index rebuilds in seconds from fresh pings (no backup needed for such short-lived data). Ongoing trips are not affected because trip state lives in the trips database.

The trip continues; the app buffers GPS points and uploads them on reconnect. If the driver cannot end the trip, support tools or the app can end it later with the buffered trail. The fare uses the trail, not the live stream.

The trip stays COMPLETED with payment PENDING. Workers retry with the same idempotency key; if it fails, the amount becomes outstanding on the rider's account and is collected before or with the next ride.