# H3 hexagonal grid > H3 is an open-source geospatial indexing system developed at Uber that maps latitude and longitude to cells in a hierarchical, mostly hexagonal grid. In system design interviews, it helps turn nearby searches and location-based counts into cell lookups, while leaving exact distance checks, data freshness, and storage scaling to your design. Source: https://sysround.com/concepts/h3 Updated: 2026-11-05 ## How h3 hexagonal grid works Choose a resolution and map each location to an H3 cell ID. H3 has 16 resolutions, numbered 0 through 15; higher numbers mean smaller cells. Store the cell ID alongside the original coordinates, such as a driver's latest latitude, longitude, and update timestamp. Build an index from cell ID to entities or aggregates. For nearby-driver search, a cell might hold driver IDs; for surge pricing, it might hold demand and available-driver counts. H3 supplies the spatial keys and operations, not the database, replication, or assignment logic. Search the query location's cell and surrounding cells to gather candidates. A grid disk covers cells within a chosen number of adjacency steps, not a fixed distance in meters. For a radius query, choose a conservative covering that cannot miss intersecting cells, then filter candidates using their coordinates and the requested distance. Use the hierarchy to change aggregation scale. A fine cell has a logical parent at each coarser resolution, so fine-cell counts can be grouped by parent ID. Most cells have seven immediate children, but pentagons differ; logical children also do not form an exact geometric subdivision of the parent boundary. Maintain the index as entities move. If a driver crosses from cell A to cell B, update membership and retain a latest-location record with a timestamp or sequence number. Expect temporary duplicate or stale entries unless updates are coordinated, and deduplicate and validate candidates before acting on them. Account for the global grid's irregularities. Most cells have six neighbors, but every resolution includes 12 pentagons, and cell areas vary within a resolution. Use H3's supported traversal functions rather than assuming a perfect planar hexagon grid everywhere. ## Worked example: Finding available drivers within 2 kilometers Suppose a ride-hailing service tracks 30,000 available drivers, each reporting a location every 5 seconds: 6,000 updates per second. Store each driver's latest coordinates, timestamp, availability, and H3 cell, plus a cell-to-driver index. For a request with a 2-kilometer radius, compute a conservative cell covering of that circle, including boundary-intersecting cells. Suppose those cells return 240 candidate IDs. Deduplicate them, fetch current records, discard locations older than the chosen freshness limit, and apply an exact distance filter. Rank the survivors by road ETA rather than H3 grid distance. Reserve the selected driver through a conditional state transition; the spatial index alone cannot prevent double assignment. ## Trade-offs - **Resolution versus query cost.** Smaller cells reduce irrelevant candidates but increase the number of cells read for a fixed search radius and the frequency of membership changes. - **Convenient neighborhoods, approximate distances.** Hexagonal adjacency supports neighborhood searches, but grid distance is neither physical distance nor road travel time. - **Spatial locality versus hot partitions.** A busy downtown cell can overwhelm one storage partition, so cell-based indexing may need subsharding and separate aggregate storage. - **Hierarchy versus geometric precision.** Parent IDs make logical rollups convenient, but exact polygon membership requires geometric checks because child boundaries do not nest perfectly. - **Freshness versus write volume.** Frequent location updates improve candidate quality but increase ingestion and index-maintenance costs, while less frequent updates require explicit staleness limits. - **Comparable buckets versus unequal areas.** Cells at the same resolution are not equal-area, so density calculations must use actual cell areas rather than treating every count as directly comparable. ## When to use it in a system design interview - The design needs nearby discovery for drivers, couriers, profiles, restaurants, or listings without scanning every location. - Demand, supply, or other events must be aggregated into geographic buckets and rolled up to broader regions. - The workload repeatedly searches neighboring areas, making explicit cell adjacency useful. - The interviewer asks how search radius, geographic precision, and partition load affect each other. ## How to bring it up in the interview - Start with the query contract: radius search, nearest candidates, polygon membership, or spatial aggregation. Explain why H3 fits that operation rather than introducing it just because the data contains coordinates. - Describe a concrete read path: map the query point to a cell, cover the search region, fetch candidates, deduplicate, check freshness, and apply exact filters. Expect questions about boundary misses and sparse areas. - Defend resolution using expected density, search radius, candidate count, and cell-read fan-out. Treat the choice as something to measure rather than assuming one resolution works equally well everywhere. - Separate the spatial index from storage ownership and correctness. Interviewers may probe hot cells, out-of-order location updates, and why finding a driver does not prevent two riders from claiming that driver. - Compare alternatives by workload: geohash offers prefix-based rectangular cells, S2 offers hierarchical spherical cells, and a database spatial index may avoid maintaining a separate cell-membership system. ## Common mistakes - Searching only the requester's cell, which misses nearby entities across its boundary. - Assuming a fixed number of neighbor rings always covers a particular radius in meters. - Using a polygon fill that selects cells by center containment as a complete candidate covering, which can miss points in boundary-intersecting cells. - Claiming H3 cells are equal-area, always hexagonal, or geometrically nested exactly across resolutions. - Treating a cell ID as a complete sharding and consistency solution, without addressing hot cells, stale memberships, or exclusive assignment. ## Interview questions where it comes up - [Design a ride hailing app like Uber](https://sysround.com/questions/design-uber): H3 can index moving drivers and support nearby candidate retrieval before ETA ranking and exclusive assignment. - [Design a food delivery app like DoorDash](https://sysround.com/questions/design-doordash): Cell-based courier indexing supports dispatch searches while exposing location freshness and movement-update trade-offs. - [Design Uber surge pricing](https://sysround.com/questions/design-surge-pricing): H3 provides spatial buckets for demand and supply counts, neighboring-area smoothing, and hierarchical aggregation. - [Design a dating app like Tinder](https://sysround.com/questions/design-tinder): H3 can narrow location-based discovery to nearby candidates before distance, exclusion, and privacy filtering. - [Design a restaurant review app like Yelp](https://sysround.com/questions/design-yelp): H3 can generate geographically relevant restaurant candidates without scanning the full catalog or losing results at cell boundaries. - [Design Facebook Marketplace](https://sysround.com/questions/design-facebook-marketplace): H3 can support radius-based listing discovery, with exact distance filtering and explicit handling of spatial query fan-out. ## FAQ ### What is Uber H3? H3 is an open-source hierarchical geospatial indexing system developed at Uber. It assigns cell IDs to locations on Earth and provides operations for neighbors, traversal, boundaries, and hierarchy. It is a library and indexing scheme, not a hosted map service or a database. ### How is H3 different from geohash? H3 uses mostly hexagonal cells, while geohash encodes locations into hierarchical rectangular cells. H3's six-neighbor structure is useful for neighborhood analysis and spatial aggregation; geohash prefixes can be convenient for storage and lookup. Both require boundary handling and exact filtering when implementing distance-based search. ### How do you choose an H3 resolution for nearby search? Start with the search radius, expected entity density, update rate, and acceptable query fan-out. Finer cells produce fewer candidates per cell but require more cell reads and more membership changes as entities move. Benchmark representative dense and sparse regions, and do not treat average cell size as a coverage guarantee. ## Related concepts - [Geohash](https://sysround.com/concepts/geohash) - [S2 geometry](https://sysround.com/concepts/s2-geometry) - [Quadtree](https://sysround.com/concepts/quadtree) - [Partitioning strategies](https://sysround.com/concepts/data-partitioning) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.