Uber

Assume 25M completed trips per day worldwide, 3M active drivers per day, 1.5M concurrently online drivers at peak, and driver pings every 3 seconds during peak. Average online drivers across the day are lower, around 800K, with pings every 5 seconds.

Assume a location ping payload of 250 bytes before protocol overhead and about 500 bytes after metadata, headers, ingestion envelope, and replication-friendly event fields. A trip record with state history, fare, route summary, rider and driver references, and audit fields is about 2 KB raw. Peak traffic is roughly 10x average for trip requests in the busiest dispatch regions.

• Trips: 25M completed trips per day divided by 86,400 seconds is about 289 trips per second on average. A 10x city and commute multiplier gives about 2,900 matching requests per second before re-dispatch attempts.
• Location writes: 800K online drivers divided by a 5 second ping interval gives 160,000 pings per second on average. At peak, 1.5M online drivers divided by 3 seconds gives 500,000 pings per second.
• Ingress bandwidth: 500,000 peak pings per second times 500 bytes per ping is about 250 MB per second before broker replication and network framing.
• Daily location events: 160,000 pings per second times 86,400 seconds is 13.824B pings per day. At 500 bytes each, that is about 6.9 TB per day raw. Keep only a short hot retention window in the streaming log and compact older data into cheaper storage if required for safety or analytics.
• Trip records: 25M trips per day times 2 KB is about 50 GB per day raw. Over one year that is about 18 TB raw. With indexes, replicas, audit history, and payment records, plan for 60 to 100 TB per year in durable stores.
• Geo-index memory: the current location index stores only the latest active driver state, not all pings. 3M active drivers times about 500 bytes is 1.5 GB raw; cell membership sets, hashes, replication, and per-region overhead can push this to 10 to 30 GB worldwide, still far smaller than the raw ping log.

• current_driver_locations.region_id, cell_id, driver_state supports nearby-driver candidate lookup by region and cell.
• current_driver_locations.updated_at supports stale driver eviction when pings stop.
• trips.rider_id, created_at and trips.driver_id, created_at support rider and driver trip history.
• trips.region_id, state, created_at supports regional operations dashboards and recovery scans.
• dispatch_offers.trip_id, offer_status supports finding active offers for a trip.
• payments.trip_id should be unique so completion retries cannot double-charge a trip.

One trip can have many dispatch offers, exactly one accepted driver assignment, many state events, and at most one successful payment capture. Current driver location references a driver but is not the source of truth for driver identity. Trip state events are append-only and can rebuild the current trip state during recovery.

At high scale, use a region-partitioned key-value or wide-column store for current locations and trip state. Current driver locations can live in Redis, Aerospike, DynamoDB, Cassandra, or a purpose-built in-memory geo index. Trips and payments need stronger durability and idempotency; they can live in a relational database per region, Spanner-like globally distributed SQL, DynamoDB with transactions, or Cassandra with carefully designed compare-and-set transitions.

Raw location pings should flow through Kafka, Pub/Sub, or Kinesis and land in object storage for short-retention analytics, safety investigations, and model training. The dispatch hot path should read the latest current location and cell membership, not scan raw event history.

Driver pings dominate write volume. At 1.5M online drivers pinging every 3 seconds, peak ingestion is about 500,000 writes per second. Treat this as a streaming workload, not a transactional database workload. The hot path should validate, deduplicate, update current location, and append to a log with backpressure.

A practical design keeps latest driver state in an in-memory or low-latency key-value store keyed by driver_id and indexed by region plus cell_id. Every ping does not need to update every downstream view synchronously. Analytics, heatmaps, fraud models, and route reconstruction consume the log asynchronously.

Location freshness is more important than perfect history for dispatch. If a ping is late or out of order, the current index should ignore it. If a driver has no accepted ping for 10 to 20 seconds, dispatch should mark the driver stale and stop offering trips until a fresh ping arrives.

Nearby-driver lookup needs a spatial index that supports frequent updates and low-latency radius search. Geohash buckets are simple: encode latitude and longitude to a string prefix, query the pickup bucket and neighbors, then expand precision or radius. The drawback is uneven cell shape and edge cases near boundaries.

QuadTrees recursively split space into rectangular cells and can adapt to density by splitting crowded urban cells more deeply. They work well for in-memory regional indexes but need careful rebalancing as density shifts. S2 cells project the sphere onto hierarchical cells and avoid some geohash distortion; they are a strong choice for global systems because cell IDs have stable hierarchy and neighbor operations.

Regardless of index type, dispatch should not trust cell membership alone. It should fetch candidate driver metadata, remove stale and ineligible drivers, compute real road-network ETA for a smaller candidate set, and expand to neighboring cells only until enough high-quality candidates are found.

The world should be partitioned into dispatch regions such as cities, airport zones, or dense metropolitan shards. A region owns its current driver index, trip requests, offer locks, surge counters, and matching decisions. This avoids a global dispatch lock and lets teams scale busy cities independently.

Region assignment normally uses pickup location for riders and latest location for drivers. Boundary cases are handled by querying neighboring regions or temporarily transferring driver ownership. Large cities can be split into polygons or S2 cell groups when a single region becomes too hot.

Geo-sharding also improves failure isolation. A routing slowdown in one city, a bad surge configuration, or a broker backlog should not affect every region. Global services such as identity and payment remain shared, but dispatch should keep enough local state to continue operating through partial outages.

The simplest algorithm chooses the nearest available driver by straight-line distance. A production dispatch service ranks candidates by pickup ETA, road distance, vehicle type, driver state, recent acceptance rate, cancellation risk, fairness, driver destination preferences, rider safety constraints, and market policy.

Dispatch must handle offer contention. A driver should not receive several overlapping offers that can all be accepted. Common approaches include a short-lived driver lock in the regional store, a compare-and-set on driver state from available to offered, or a lease tied to offer expiration. If the driver rejects or times out, the lease is released and the next candidate is tried.

Batch offers can reduce rider wait time but increase driver spam and duplicate accepts. Sequential offers are simpler and fairer but can be slower. A strong interview answer starts sequential, then discusses controlled parallelism for high-demand or low-supply situations.

Surge pricing balances marketplace demand and supply. Compute it over small geo-time windows such as S2 cells or city neighborhoods every 30 to 60 seconds. Inputs include open ride requests, available drivers, accepted trips, cancellations, driver arrival rates, weather, events, and historical baselines.

The multiplier should be smoothed to avoid oscillation. If one cell jumps from normal to high surge every minute, riders and drivers see confusing prices and may game boundaries. Use dampening, caps, minimum duration, and neighborhood blending. Once a rider confirms a trip, freeze the quoted multiplier for that request so the fare does not change while dispatch retries.

Surge is also an operations and trust issue. The pricing service should expose explainability, audit logs, emergency caps, and local regulatory controls. Dispatch can use incentives separately from rider surge, for example paying drivers bonuses without changing rider price.

Model the trip lifecycle as a strict state machine: request, match, enroute, ongoing, complete, payment captured, plus terminal cancellation and payment failure paths. Each transition should be an idempotent command with actor authorization and expected state version. This prevents duplicate accepts, double starts, and double payments.

Routing and ETA are advisory but critical to user experience. Dispatch can use rough distance to shortlist candidates, then call maps for top candidates. During an active trip, route updates can be cached or throttled because every location ping should not trigger a full route recomputation.

Notifications are best-effort delivery mechanisms, not the source of truth. The apps should poll or maintain a socket for authoritative state. Payment capture happens after completion with an idempotency key based on trip_id, so retries cannot charge twice. If payment is delayed, the trip can still complete while collections and support workflows continue.

Alternative one is a central global dispatch service. It is easier to reason about initially, but it becomes a latency, availability, and coordination bottleneck as cities and location writes scale.

Alternative two is purely nearest-driver matching. It is simple and fast, but it ignores road ETA, driver acceptance probability, fairness, cancellations, and marketplace health. It works for a prototype but not for a mature ride-hailing product.

Alternative three is to outsource maps, pricing, notifications, and payments entirely. This accelerates launch, but the product still needs local fallback behavior, idempotent state transitions, and strong observability because those dependencies directly affect trips.

Do not use this architecture for scheduled long-haul logistics, public transit planning, or fleet management where dispatch can be optimized in batches over minutes or hours. Ride-hailing needs second-level decisions, mobile push reliability, and real-time location freshness; slower planning systems can trade latency for global optimization.