Uber Surge Pricing & Geospatial Architecture

Uber's H3 system divides the Earth's surface into hexagons at 16 resolution levels, from continent-scale down to roughly 1m² cells. Hexagons have a critical geometric advantage over squares: all six neighbors are equidistant from the center cell, eliminating the diagonal-distance problem where square-grid corner neighbors are √2× farther than edge neighbors. This means 'find all drivers within k cells' returns a uniform circular area rather than a diamond. H3 supports hierarchical containment — a resolution-7 cell contains exactly 7 resolution-8 children — enabling multi-resolution aggregation for surge pricing and demand forecasting.

Every active driver's phone sends a GPS update every 4 seconds via a persistent connection. These updates flow through Kafka into a geospatial index service that converts each (lat, lng) to an H3 cell ID at resolution 7 (~5km² cells). The service maintains an in-memory map of cell → [available_driver_ids], continuously updated as drivers move between cells. When a rider requests a ride, the system queries the rider's cell and its k-ring neighbors (concentric hexagonal rings) to find nearby available drivers. This spatial index is sharded by geographic region and replicated across availability zones.

Uber computes a surge multiplier per H3 cell by comparing rider demand (open ride requests) to driver supply (available drivers) within a sliding time window. The algorithm blends current real-time conditions with short-term predictions from event calendars, weather data, and historical day-of-week patterns. Surge multipliers are spatially smoothed — adjacent cells have similar values to prevent jarring price cliffs at cell boundaries. The system recalculates pricing every 1–2 minutes per cell, and the multiplier incentivizes drivers to move toward high-demand areas.

When a rider requests a trip, Uber's dispatch system (DISCO) solves a batched bipartite matching problem: given N available drivers and M pending requests in a region, find the assignment that minimizes total expected pickup time. This is approximated from the Hungarian algorithm for real-time performance. The system considers not just Euclidean distance but live traffic conditions, driver heading direction, road network topology, and even which side of the street the driver is on. The entire dispatch decision — from request to driver notification — completes in under 100ms.

All location updates, trip lifecycle events, pricing signals, and ETA computations flow through Apache Kafka. Uber's Kafka deployment handles millions of messages per second with sub-second end-to-end latency. Topics are partitioned by geographic region, ensuring all events for a given area are processed by the same consumer group for ordering guarantees. This event-driven architecture cleanly decouples the GPS ingestion, surge pricing, and dispatch subsystems — each can scale and deploy independently without tight coupling.