Redis Cluster Slot Migration: How Traffic Keeps Flowing While Slots Move

Redis Cluster does not shard by key. It shards by 16384 hash slots, and every master owns a contiguous range. A key maps to a slot via CRC16(key) % 16384, and the slot maps to a master. The indirection is the whole point. Slots are cheap to move. Keys are not.

Normal routing is pull-based and lives on the client. The client hashes the key, computes the slot, looks up the owning master in its local slot cache, and sends the command directly. No proxy. Latency stays at one round trip.

The slot cache will go stale. That is fine, because Redis tells the client when it is wrong. Send a command for slot 5000 to a node that no longer owns it, and the node replies MOVED 5000 10.0.0.4:6379. The client refreshes its routing table, resends to the correct node, and moves on. MOVED is not an error. It is how Redis keeps clients converged on the truth without a central coordinator.

Resharding works through this same mechanism. An operator marks a slot range as migrating from A to D. Keys move incrementally in batches. During the window, the cluster is in a half-and-half state, and Redis distinguishes two cases.

If the key has already been migrated, A returns MOVED and the client retries against D permanently. If the key is still on A, A serves it. If the client asks for a key that has migrated mid-transaction, A returns ASK 5000 10.0.0.4:6379, meaning "send this one request to D, but do not update your cache yet." ASK is a one-shot redirect for the migration window. MOVED is a permanent topology change.

The result: traffic keeps flowing during resharding. No global pause, no downtime, no read-only mode. Clients converge on the new slot map naturally as they hit redirects.

Hash tags fix the multi-key case. A MGET or a Lua script across two keys works only if both keys live on the same node. Wrap part of the key in braces to force them into the same slot: {user:42}:profile and {user:42}:cart both hash on user:42 and land together. Forget the braces and your transaction returns CROSSSLOT.

The production failure mode worth knowing. A client library configured with a fixed node list and no MOVED handling will receive the redirect, ignore it, retry the same node, get another MOVED, and loop. Every retry hits the wrong node. Throughput collapses. Add an aggressive connection pool and the cluster spends its CPU answering MOVED to clients that will never listen. Always use a cluster-aware driver and verify it actually respects redirects under chaos testing.

Failover does not move slots. A replica is promoted, the slot range stays put, and only the leader role swaps. Slot ownership is the stable thing. Leadership is not.