Uber’s Real-Time Architecture Was Built Around a Problem That Is Genuinely Hard

H3: The geospatial decision that actually makes sense at any scale

Uber open-sourced H3, their hierarchical hexagonal geospatial indexing system. H3 divides the Earth into hexagonal cells at 16 resolution levels. Hexagons, unlike squares, have equal distances from the center to all neighbors, making geographic computations (nearest driver, surge zone boundary, coverage area) consistent in all directions.

H3 is a genuine technical contribution that transfers: any application doing geospatial computation benefits from hexagonal indexing over square grids. It’s a 5-line implementation decision, not a scaling decision. If you’re building geofencing, delivery zones, or coverage analysis, H3 is worth adopting regardless of your scale.

Cassandra: Scale-dependent

Uber uses Apache Cassandra for certain high-write workloads (GPS coordinates, trip events). Cassandra is optimized for write-heavy workloads with geographic distribution across datacenter. GPS updates from millions of active drivers refreshing every 4 seconds is a write profile that Cassandra’s architecture is well-suited for.

At 10,000 drivers (a meaningful scale for a city-level startup), PostgreSQL with time partitioning handles GPS data comfortably. At 7 million active drivers globally, the case for Cassandra’s write throughput and multi-datacenter replication becomes compelling. The decision is scale-gated.

Machine learning for ETA

Uber’s ETA prediction uses gradient boosting across road network data, historical trip data, real-time traffic, weather, and time-of-day features. The ML pipeline processes billions of data points. This is a specifically hard problem, accurate ETA prediction in unfamiliar cities, during events, in adverse weather is not a pattern transfer.