Resharding is the process of moving hash slots from one Redis Cluster node to another while the cluster continues serving traffic.

The goal is easy to state:

move ownership of a slot without losing keys or confusing clients

The difficulty is that ownership, storage, and client routing do not all change at the same instant.

Migration Has Two Sides

During resharding, the source and target nodes enter complementary states:

source: slot is MIGRATING to target
target: slot is IMPORTING from source

Those states tell the cluster that the slot is in motion. Some keys may still live on the source. Some may already have moved to the target. Clients may still have an old slot map.

The system needs to handle all of that without pretending the move is instantaneous.

Moving Keys Safely

For each key in the migrating slot, the source transfers the key and value to the target. Once the target confirms receipt, the source can delete its copy.

Conceptually:

source serializes key
target imports key
source deletes key after success

The exact Redis commands and protocol details are more specialized, but the safety principle is simple: do not drop the source copy until the target has the data.

ASK Is Temporary, MOVED Is Durable

Redis Cluster has two important redirection styles.

MOVED means the client's slot map is stale. The slot belongs somewhere else now, and the client should update its topology view.

ASK means the slot is currently migrating, and this particular request should go to another node for now. The client should not permanently update its slot map just because it saw ASK.

During migration, the source may still serve keys it has not moved. If a key has already moved, the source can send an ASK redirect to the target. The client then sends ASKING to the target before the command, allowing the target to accept this temporary wrong-slot request.

That distinction lets Redis preserve stable slot ownership until migration is complete while still serving keys that have already moved.

Finishing The Slot Move

Once all keys in the slot have moved, the cluster can switch ownership:

source clears MIGRATING
target clears IMPORTING
slot owner becomes target
cluster metadata version advances
clients learn through MOVED or topology refresh

After that, MOVED becomes the correct response for clients still sending the slot's commands to the old owner.

Resharding Is About Transitional Truth

The hard part of resharding is not copying bytes. It is representing the in-between state truthfully.

Before migration, the source owns and stores the slot. After migration, the target owns and stores it. During migration, the source may own the slot while individual keys are split across source and target.

Redis handles that transitional truth with slot states, temporary redirects, and careful key transfer. The cluster remains available because it has a vocabulary for "moving" rather than only "here" or "there."