Redis Cluster assigns keys to hash slots and places those slots on primary nodes. During a reshard, a client may receive MOVED for a settled location or ASK while a slot is being migrated. A client that treats either response as a normal application failure can turn maintenance into user errors; a client that never refreshes its slot map can keep sending traffic to old owners. Multi-key operations generally require their keys to reside in one slot. Hash tags can deliberately co-locate related keys, but concentrating too many hot keys in one slot creates a capacity ceiling that resharding cannot split without changing the key contract.
Make this comfortable
Redis Cluster resharding: require redirect-aware clients and compatible key placement
Operational decision
A billing service atomically adjusts two counters for one account. It uses account-scoped hash tags for those counters, such as bill:{acct-7284}:used and bill:{acct-7284}:limit, after proving the two-key operation is required. In a disposable reshard drill, move the slot while 29 clients issue reads and updates. Record MOVED and ASK handling, retries, duplicate application effects, per-node latency, and final counter values. Clients must refresh routing and obey retry budgets. The team also measures the busiest account slot; if one account alone saturates a node, moving that slot merely relocates the hotspot. A new key model or workload split is needed.
Keys: bill:{acct-7284}:used, bill:{acct-7284}:limit
Operation: same-slot two-key update
Concurrent clients: 29 during slot move
Expected: redirect-aware retries; final counters reconcile
Hot-slot check: top account rate versus node capacityCost and verification
A reshard consumes network bandwidth, CPU, and key-movement time. Large values and hot slots increase the duration of mixed ownership. More cluster nodes do not reduce the cost of a single hot key or all keys trapped by one hash tag. Test the client library and configured retry deadlines under both redirect types rather than assuming an old client supports live migration. Maintain a stable business request ID across redirected retries when the update has effects outside Redis. Capacity planning should use per-slot and per-node tails, not only cluster-wide average utilization.
Common Mistakes
- Do not use an ordinary single-node Redis client against a resharding cluster.
- Do not assume hash tags are free: they can create an unsplittable hotspot.
- Do not ignore multi-key slot requirements until production resharding.
Connected lessons
- DevOps: delivery, infrastructure, and reliable operations
- Queue-age scaling: target completion time, not only queue length
- Redis maxmemory: choose eviction behavior by the meaning of each key
- Retries and timeouts: bound the cost of a failed request
- Redis persistence: state the recoverable write window before choosing AOF or snapshots
Practice and check
devops
redis
data-operations