INFRA Signal 213
Redis cluster cannot batch MSET across different hash slots
↗
Illustration only Photo by Benjamin Child on Unsplash
Comments
The event shows that a common caching pattern fails in a production Redis cluster because multi-key commands can only operate within a single hash slot. This forces developers to redesign batching logic or accept per-key round trips, increasing latency and operational cost.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
Clustered Redis distributes keys across 16384 hash slots using CRC16(key) mod 16384
MSET and other multi-key commands require all keys to reside in the same slot
Different origin and destination hexes generate keys that almost never share a slot
THE READ
What the cluster adds up to.
The change is the emergence of a hard technical constraint in a widely used data store: a multi-key command cannot span slots, so any key design that spreads requests across many slots cannot be batched.
Adopting the naive H3-based cache requires writing keys that are unlikely to share a slot, which means the application must either issue many single-key writes or restructure the key format to force locality.
The cost is higher latency and more network round trips, while the benefit of reduced routing engine calls may be lost if the cache cannot be persisted efficiently.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER