Routing the globe with geohash prefixes

A geohash is a string that encodes a lat/lon as a prefix of a Z-order curve. Prefixes of a geohash represent containing tiles — a 4-character geohash is a region, a 5-character geohash is a subregion inside it. The World Monitor uses geohash prefixes as tile keys: a signal is upserted with its geohash, a client viewport is mapped to the geohash prefixes it covers, and the realtime WS streams deltas only for the tiles in the viewport. Routing is prefix matching, which is an operation Postgres does natively and fast, without a spatial extension.

Why geohash, not PostGIS

PostGIS is a database extension that adds spatial types and functions. It is powerful, and it puts geo logic in the database layer. DEINO architecture keeps logic in the domain and storage behind a port — putting geo routing in PostGIS would put logic in the adapter, which is the layer the port rule says to keep thin. Geohash routing keeps the geo math in deino-core::geo, where it is pure functions over types the compiler checks. The database stores the geohash string and does prefix matching; the domain computes the tile keys and the viewport coverage. That is the hexagonal rule applied to geo: the logic is in the core, the storage is behind the port, and the spatial extension is not needed.

The tile key is a string. Routing is prefix matching. The database already does that fast, and the domain computes the prefix — PostGIS is not needed, and the geo logic stays in the core.

• Geohash prefix = tile key: a string, not a geometry. Routing is string matching.
• Per-tile broadcast: one channel per geohash; a client receives only its viewport.
• deino-core::geo computes the prefix; Postgres stores it — logic in the domain, storage behind the port.

Realtime, per tile

The realtime WS (GET /api/v1/atlas/ws) streams deltas through GeoHub — one broadcast channel per geohash tile. A client sends its viewport; the server maps it to the geohash prefixes it covers and subscribes the client to those channels. The client receives deltas only for its viewport, not the whole globe. That is per-tile routing, and it works because the tile key is a geohash prefix — a string the database and the broadcast hub both use as the routing key. No spatial index, no PostGIS; just prefix matching and a channel per prefix.

What this costs, and what it buys

Geohash precision is variable — longer prefixes are smaller tiles, shorter are larger. The trade is that tile boundaries are grid-aligned, not natural (a geohash tile does not follow a coastline), which means a viewport near a tile edge may subscribe to one extra tile. That is a bandwidth cost, not a correctness cost — the signal is still delivered, and the client filters to its actual viewport. What it buys is a geo layer with no spatial extension dependency, geo logic in the pure domain, and a realtime routing key that is a string. We are building the POC; the geohash routing is built, and the per-tile broadcast is built.

Why the logic is in the core

The geohash computation — lat/lon to prefix, viewport to prefix set — is in deino-core::geo, not in a PostGIS function. That means the geo logic is testable without a database, compilable in the domain crate, and governed by the same type system that governs every other domain value. A spatial extension puts the logic in the storage layer; geohash puts it in the domain, where the hexagonal rule says logic lives. The database stores the result; the core computes it. That is the rule, applied to geo, and it is why the World Monitor has no PostGIS dependency.

PostGIS puts geo logic in the database. Geohash puts it in the domain, where the compiler checks it and the port rule governs it. The database stores the key; the core computes with it.

— geo design note