How it works
Geohash repeatedly divides longitude and latitude ranges, interleaves the resulting bits, and encodes them using base32 characters. Each character adds five bits of precision, so longer strings identify smaller cells.
Prefixes form a hierarchy: every location whose geohash starts with the same prefix belongs to the same larger cell. For example, cells beginning with "9q8yy" sit inside the cell "9q8y". Nearby points often share a prefix, but points on opposite sides of a cell boundary may have very different prefixes.
Store each object's ID, coordinates, and geohash in a spatial index. One implementation maps a fixed-length cell code to object IDs; another uses an ordered index on full geohashes so a prefix becomes a range scan. An ordinary hash index on full strings does not support arbitrary prefix scans.
For a radius search, select a precision and enumerate cells that cover the search circle, or its bounding box. Fetch candidates from those cells, deduplicate IDs, and calculate geographic distance using their coordinates. Discard candidates outside the radius and sort the survivors by distance or the product's ranking rules.
Searching the current cell and its eight neighbors is sufficient only when those cells cover the requested area. Larger radii require more cells or a coarser precision. For moving objects, update coordinates continuously and change cell membership when they cross a boundary; timestamps, versions, and expiration help prevent stale entries from appearing current.
A worked example
Finding available drivers within 2 kilometers
A rider requests drivers within 2 kilometers. At the chosen precision, suppose the circle's bounding box intersects 24 cells. The service reads all 24 buckets and gets 900 index entries. It deduplicates driver IDs, loads their latest coordinates and availability, and applies a 15-second location-age limit. A geographic distance calculation leaves 260 available drivers inside the circle; these are ranked for matching, potentially using road travel time. If the query is too expensive, finer cells may reduce candidate reads but increase bucket lookups. Coarser cells do the reverse. Drivers crossing boundaries need versioned membership updates, and the final assignment still needs an atomic claim because two riders may select the same driver.
Trade-offs to say out loud
- Precision trades candidate count for query fan-out
- Smaller cells reduce irrelevant candidates but require more cell lookups to cover the same radius.
- Simple indexing needs geometric filtering
- Geohash cells are rectangles, so cell membership alone cannot answer an exact circular-radius query.
- Geographic grouping creates hot spots
- Dense downtown cells can overload individual keys or partitions, requiring finer cells, subsharding, or another indexing strategy.
- Moving objects create maintenance work
- Cross-cell moves require removing old membership and adding new membership, with temporary duplicates or omissions unless updates are coordinated.
- Cell dimensions vary by latitude
- A fixed geohash length does not provide uniform physical cell dimensions worldwide, so coverage logic must use geographic bounds rather than a universal kilometer estimate.
- An encoding is not a complete spatial database
- Geohash provides useful keys, but efficient nearest-neighbor search, concurrency control, and distributed ownership still require additional design.
When to reach for it
- The main read is “find drivers, couriers, restaurants, listings, or profiles within this radius.”
- You need a concrete spatial candidate index that can be implemented with cell buckets or ordered key ranges.
- Location updates are frequent enough that cell membership, stale coordinates, and expiration deserve an explicit design.
- You need hierarchical geographic buckets for local aggregation or caching, and can tolerate rectangular cell boundaries.
How to bring it up in the interview
- Start with the query contract: radius or nearest K, expected density, freshness requirements, and whether ranking uses straight-line distance or travel time.
- Draw a search circle crossing cell boundaries and explain the covering-cell lookup followed by exact distance filtering; interviewers often probe missing neighbors first.
- Connect precision to workload: estimate cells queried, candidates per cell, and location-update volume rather than choosing a geohash length by habit.
- Separate spatial indexing from physical sharding: explain how dense cells are distributed and how a query merges results from multiple partitions.
- For moving objects, describe versioned updates, expiration, and authoritative eligibility checks; a nearby-driver index does not prevent double assignment.
Common mistakes
- Searching only the user's geohash prefix and missing nearby objects across a boundary.
- Assuming the current cell plus eight neighbors covers every search radius.
- Treating matching prefixes or lexicographic geohash order as exact distance ordering.
- Returning the nearest K candidates from an arbitrary subset of cells without proving that unsearched cells cannot contain closer results.
- Using one cell as one physical shard without accounting for density skew, or claiming that more geohash characters make noisy GPS coordinates more accurate.
Where it comes up
Interview questions where geohash is part of a strong answer, and why.
- Design a ride hailing app like UberNearby-driver discovery requires a spatial candidate index that handles frequent movement, boundary crossings, and stale locations.
- Design a food delivery app like DoorDashCourier dispatch needs nearby-courier retrieval before evaluating availability, pickup timing, and travel time.
- Design a dating app like TinderLocation-based discovery needs bounded spatial retrieval before applying exclusions, preferences, and privacy rules.
- Design a restaurant review app like YelpNearby restaurant discovery needs complete geographic coverage before filtering and ranking results.
- Design Facebook MarketplaceLocal listing search needs a spatial index to avoid scanning all listings while preserving radius and ranking semantics.
- Design Uber surge pricingSpatial demand and supply aggregation needs geographic buckets whose precision and boundaries affect signal quality and pricing stability.
Questions people ask
How does geohash proximity search work?
Use geohash cells to retrieve a candidate set covering the requested search area, including cells across boundaries. Then calculate distance from the original coordinates and filter by radius. Geohash narrows the search; it does not calculate distance or automatically return nearest neighbors.
What geohash precision should I use?
Choose precision based on query radius, local density, and the cost of cell lookups versus candidate filtering. At the equator, a five-character cell is roughly 4.9 by 4.9 kilometers, while a six-character cell is roughly 1.2 by 0.61 kilometers. East-west width shrinks toward the poles, so use actual cell bounds when constructing query coverage.
What is the difference between geohash and a quadtree?
Geohash is a fixed hierarchical encoding that works well as a string or integer key. A quadtree recursively divides space into four children and can adapt its subdivision to data density. Compare them on query coverage, update cost, density skew, and storage support rather than assuming either is universally faster.