Geohashing — Part 2: Internals & Implementation

maang.io System Design Series

What is this?

Back to the twenty-questions map game. In Part 1 we played it from the outside — ask, halve, write down the answer, get a string. Now we go under the hood and watch the machine that plays it: how the bits actually get interleaved, why the resulting string traces a curious Z-shaped path across the map, why that Z-shape is the secret cause of the boundary problem, and how a production system like Redis turns the whole game into a single 64-bit integer it can sort. By the end you'll be able to encode a coordinate by hand, decode one back to a bounding box, compute a cell's eight neighbours, and explain exactly why two points ten metres apart can end up with wildly different geohashes.

The one-line idea: A geohash is a Z-order (Morton) space-filling curve — it visits 2-D cells in a fixed 1-D order by interleaving the bits of the two coordinates. That interleaving is what makes prefixes mean proximity, and the discontinuities in the Z-curve (the big jumps where it snakes back) are exactly what makes the boundary problem unavoidable. Everything in this chapter follows from that one fact.