A look at how Uber finds nearby drivers. Uber finding nearby drivers is the textbook real-time geospatial problem: a rider requests a car, and within ~1 second the system has to find the closest available drivers, compute ETA for each, surface them to the rider, and let one accept, across millions of concurrent riders, drivers, and trips in 70+ countries. The architectural bet that makes it work is the H3 hex grid, Uber’s open-source discrete global grid system.
How Uber Finds Nearby Drivers: The problem at scale
Uber’s matching problem isn’t “find drivers within X distance” . That’s a postgis query. The real problem is doing it in < 1 second, for millions of concurrent riders, against a driver pool that updates position every 4 seconds, while also computing ETA (which depends on the road network, not straight-line distance), and assigning surge multipliers per region. Every dimension of this is hard: write throughput (millions of driver position updates per minute), read throughput (millions of rider match queries), spatial indexing, road-network ETA, and pricing. A naive postgis "ST_Distance" implementation collapses instantly.
The core architecture
Every driver app reports its GPS position every ~4 seconds to Uber’s ingest pipeline, which writes the (driver_id, lat, lng, status) tuple into a Redis geospatial index keyed by H3 cell ID. H3 is Uber’s hexagonal grid that tiles the planet at 16 resolutions; resolution 9 (~174m cells) is roughly what Uber uses for driver indexing. When a rider requests a ride, the API + Match service takes the rider’s pickup point, finds its H3 cell, and queries the driver positions in the pickup cell plus the 6 adjacent hexes. That gives a candidate set of nearby drivers in single-digit milliseconds. OSRM + ETA then computes real road-network travel time to each candidate (not straight-line), and Surge Pricing multiplies the base fare based on demand/supply ratio in that cell.
Why H3, not a regular grid or a KD-tree
Uber explicitly chose H3 over alternatives for three reasons. Hexagons have equal-distance neighbors: every hex has 6 adjacent hexes, all equidistant from the center. A square grid has 8 neighbors but they’re not equidistant (corners are farther). Hexagons tile the sphere cleanly: H3 uses a hierarchical icosahedral projection, so the grid works at any latitude without distortion. H3 has a stable cell ID encoding: the H3 index is a 64-bit integer that encodes the cell’s position at every resolution, so you can compute “what cells are near me” with bit arithmetic, not spatial queries. This makes neighbor lookups O(1).
The cell ID is also the sharding key for surge pricing. Per-cell demand vs supply is computed continuously and stored alongside the driver index.
The driver-position cache is the bottleneck and the design point
Driver positions are write-heavy (every 4s per driver) and read-heavy (every rider request queries hundreds of positions). The Redis geospatial index uses Redis’s built-in GEO commands (backed by a sorted set on a geohash), but the index is partitioned by H3 cell ID so a single query only touches the relevant cells. TTLs handle driver disconnections: if a driver’s position hasn’t been updated in 30 seconds, it’s evicted from the cache and treated as unavailable. This is why your driver sometimes “disappears” briefly on the map: their app stopped updating position (network drop, background kill), and the cache evicted them. They reappear when the app reconnects.
The one non-obvious insight
Uber’s surge pricing isn’t computed globally. It’s per-cell. The demand/supply ratio in a single H3 cell can spike independently of neighboring cells (a concert ends, a neighborhood floods with ride requests). The H3 grid means Uber can mark up prices cell-by-cell in real time, which is why you’ll sometimes see surge of 2.0x at one corner and 1.2x three blocks away. The grid is the pricing granularity. Without the per-cell model, surge would be city-wide, which is too coarse to actually balance supply and demand.
Uber’s driver-matching is the canonical H3-hex-grid architecture. Equal-distance neighbors, stable cell IDs as sharding keys, and per-cell surge pricing are what made planet-scale ride-hailing computable in under a second. H3 is now open-source and used by dozens of geo-services. It’s one of the most-copied pieces of Uber’s infrastructure.
Continue learning: