Uber: geospatial indexing

01 · CONTEXT

The problem: analyzing the map in cells

A ride-hailing marketplace needs to answer questions about regions, not isolated points: how much demand and how much supply exist here? For that, raw latitude and longitude are not enough; you need a way to turn the map into cells with identifiers that can be counted, compared, and grouped. In an interview, start with gathering requirements: what precision is needed, what kind of neighborhood matters, and whether the region needs to be seen at different scales (neighborhood, city).

Uber's answer was to create H3. The motivation stated on the engineering blog is to combine the benefits of a global hexagonal grid with a hierarchical indexing system. In other words, H3 is a grid of hexagons with a hierarchy of resolutions, not an index based on squares. Uber uses H3 as the grid system for analysis and optimization across its marketplaces.

02 · WHY HEXAGONS

The cell shape changes the analysis

According to Uber, using the hexagon as the cell shape is critical to H3. The central reason is neighborhood: in a hexagon there is a single distance between the center of the cell and the center of each neighbor, whereas in a square there are two distances and in a triangle, three. In square grids, analysis requires distinct sets of coefficients, because side neighbors and diagonal neighbors are not equivalent.

In practice, this uniformity simplifies operations such as smoothing values across neighboring cells or analyzing gradients: the result does not depend on whether the neighbor is to the side or on the diagonal. That is what makes sense for estimating, for example, how demand spreads from one region to the next.

03 · HIERARCHY

Resolutions and the parent-child approximation

H3 offers sixteen resolutions. At each finer resolution, cells have one-seventh the area of the cells at the previous, coarser resolution. So the same point can be described coarsely (city) or in detail (block), just by changing the resolution.

There is an important caveat: the finer cells are only approximately contained in the parent cell, because hexagons do not subdivide exactly into smaller hexagons. On the other hand, a child cell's identifier can be truncated to find the ancestor cell at a coarser resolution, which makes climbing the hierarchy cheap. When designing, treat grouping by parent as an approximation and not as an exact partition.

1. The client sends the position of a point on the map; the system needs to group it into a cell before any regional analysis.

2. The indexing service converts the position into a hexagonal cell identifier at the requested resolution.

3. The truncated identifier gives the ancestor cell at a coarser resolution; that cell's aggregate is read from the cache, knowing that grouping by parent is only approximate.

04 · IN THE MARKETPLACE

Dynamic pricing per cell

Uber itself describes the best-known use: dynamic pricing is computed by measuring supply and demand in hexagons of each city served. H3 makes it possible to analyze geographic information to set dynamic prices and make other decisions at city scale.

As an architecture, the pattern is: position events from riders and drivers arrive through a message queue, are aggregated by cell, and feed a pricing service read on each request. Since the natural key is the cell, the counters distribute well across nodes, and the design connects with real-time analytics and with choosing a good particionamento key. This design is a didactic interpretation; Uber's blog does not detail the infrastructure.

1. Riders and drivers send positions and requests through the system edge.

2. Position events go into a queue, decoupling ingestion from aggregation.

3. A consumer converts each position into a hexagonal cell and updates that cell's supply and demand in fast storage.

4. The pricing service reads the cell's supply-to-demand ratio to set the dynamic price in that region.

5. If the aggregate storage goes down, the region's price has no current data and you must decide between using the last known value or a default value.