You are designing a 'vehicles near me' lookup on Redis Cluster for a fleet of two million vehicles that report their position every few seconds. How would you lay out the geospatial keys, and what specifically breaks if you keep every vehicle in a single key?

## Framing the problem Two million vehicles reporting every few seconds is on the order of 300k–700k writes per second, plus a read whenever a rider opens the app. The question is not "can Redis do geo" — it can — but how the key layout maps that load onto shards and onto the single command-execution thread of each shard. ## What a single global key costs you **It is one slot on one shard.** Redis Cluster distributes by key, and resharding relocates whole keys. A key holding all two million members lives entirely on one primary; adding shards does not relieve it. That is the fundamental ceiling: your capacity is one node's capacity, forever. **Writes and reads serialise against each other.** Every `GEOADD` and every `GEOSEARCH` for the whole product queues on that one shard's execution thread. Position updates are individually trivial, but at hundreds of thousands per second they saturate a core, and a query's latency now includes waiting behind them. **Query cost tracks density, not just key size.** `GEOSEARCH` scans the covering geohash cell plus its eight neighbours and then distance-filters the candidates. In a dense downtown a 5 km radius touches an enormous number of members; that work happens inside one command, so it delays every other client on that shard. A single unbounded query in the busiest city is enough to produce a visible latency spike. **Operations get worse as the key grows.** Deleting or migrating a multi-million-member sorted set is expensive; snapshots and replica sync carry the whole thing; and the memory of that one key is bounded by one node's RAM. ## The layout that works: geographic partitioning Split the index by area so both writes and queries spread across shards. **Option A — one key per operational region**: `veh:{sf}`, `veh:{nyc}`. Natural if the business already thinks in cities and dispatch never crosses them. Simple to reason about, but load is as skewed as your cities are — one megacity is still a hot shard. **Option B — one key per fixed-precision geohash cell**: `veh:{9q8y}` using, say, a 4–5 character geohash prefix so each cell is a few kilometres across. This spreads dense regions across many keys automatically and puts a natural ceiling on any one key's size. The cost is fan-out: a query centred near a cell edge, or with a radius larger than a cell, must query the containing cell plus its neighbours and merge the results. With either option, hash tags (`{sf}`) let you co-locate related keys deliberately — for example a region's geo index and its last-seen sorted set — so a Lua script or a `GEOSEARCHSTORE` involving both stays inside one slot. **Client-side fan-out** is the price of partitioning: issue N `GEOSEARCH` calls in parallel (pipelined per shard), concatenate, re-sort by distance and truncate to the requested count. Cap N by choosing a cell size comfortably larger than the typical search radius, so the common case touches 1–9 cells and not hundreds. ## Shaping the write path - **Suppress non-movement.** A parked vehicle re-reporting the same coordinate is pure load. Publish only when displacement exceeds a threshold or a heartbeat interval elapses. - **Batch.** `GEOADD` accepts many triples per call; aggregating a few hundred milliseconds of updates per region collapses round trips and per-command overhead dramatically. - **Keep member names short.** Member strings dominate sorted-set memory; use a numeric ID, not a UUID string or JSON. - **Handle region crossing.** A vehicle moving between cells must be `ZREM`ed from the old key and `GEOADD`ed to the new one. Because those keys may be in different slots, that is two commands and is not atomic — a brief double or missing presence is acceptable for a candidate index, but the writer must be idempotent and the reader must tolerate duplicates. ## Staleness: there is no per-member TTL A geo member is a sorted-set member; TTL exists only on the whole key. So a crashed client's vehicle stays in the index forever unless you remove it. The standard pattern is a parallel sorted set per region scored by last-seen epoch, updated in the same pipeline as `GEOADD`; a sweeper periodically runs `ZRANGEBYSCORE seen -inf <cutoff>` and issues `ZREM` on both keys in bounded batches. Readers should additionally treat a position older than a few seconds as unusable. An alternative for genuinely ephemeral data is a rolling key per time window (`veh:{sf}:<minute>`), with an `EXPIRE` on the whole key and queries covering the current and previous window. It trades duplicate members across windows for free expiry. ## Reads `GEOSEARCH` is a read-only command (unlike the deprecated `GEORADIUS`, whose optional `STORE` made it a write), so replicas can serve proximity queries. Always send `COUNT n` with `ASC` to bound both work and reply size; consider `COUNT n ANY` where "some nearby vehicles" is acceptable and "the nearest" is not required — it short-circuits instead of ranking the whole candidate set. ## When to leave Redis If the queries stop being "points inside a circle or box" — polygon geofences, route-time ranking, road snapping, multi-attribute filters like *nearby AND electric AND rated > 4.5* — Redis is the wrong arbiter. The durable pattern is Redis as a millisecond candidate generator that reduces millions of vehicles to tens, with the precise, expensive logic running on that shortlist.