Cluster Resharding Practice

During migration, the source may still own the slot while some individual keys have already moved to the target.

They can never disagree, because ownership transfers atomically with the keys in a single cluster transaction.

The disagreement is an illusion caused by stale client-side slot caches, not by keys actually moving early.

Keys move only after ownership flips, so the target may own the slot while the keys still sit on the source.

ASK means update the slot map permanently, while MOVED is the one-time redirect used only during migration.

ASK is returned for read commands and MOVED for write commands, so the type of command decides the redirect.

ASK is temporary for a key during migration; MOVED means the stable slot owner has changed and the slot map should be updated.

They are interchangeable hints, and a client may safely treat both as MOVED since both name the correct node, and updating the slot map on either one costs nothing extra.

The source keeps the key so reads stay fast during migration; deletion simply waits for the next eviction cycle.

Keeping the source copy until import confirmation prevents losing the key if transfer fails partway through.

Keeping the copy lets both nodes serve writes for the key, doubling throughput while the migration runs.

The key must remain because slot ownership cannot change while any key in the slot still exists on the source.

Only client caches change; the cluster keeps the migrating and importing flags so future migrations start faster.

Each transferred key is tagged with the new node's ID, while the slot-level state stays unchanged.

The source deletes the slot from its table, and clients learn the new owner only through subsequent ASK redirects, since MOVED is reserved for failover-driven ownership changes.

The slot state changes from migrating/importing to the target as stable owner, and clients should later receive MOVED for stale routing.

It cannot make progress; a stale client must refetch the full slot map before any command will succeed.

A stale client can follow ASK during migration and MOVED after completion, so it can make progress while learning the new route.

It should retry the same node with backoff until the slot map converges, because redirects are advisory only.

It makes progress only for reads; writes from stale clients are rejected until the client performs a new handshake.