Live Shard Rebalancing Service

Move one bounded key range from a source shard to a destination without changing its data schema. Storage supports consistent snapshot/log pairing and versioned writes. Routers can be stale, so shard servers must enforce ownership.

Moving a range must preserve a single writable owner while copying changing state. Analyse snapshot/log boundaries, delete ordering and the exact point where old-epoch writes become impossible.

Begin with source-only writes and private destination replay. Switching routers after a bulk copy does not stop stale clients or late writes. Fence the source, drain a final barrier and conditionally activate the new ownership epoch.

1. Keep one writable authority for the moving range.
2. Copy a snapshot and replay updates without gaps.
3. Fence the old owner before publishing the new directory epoch.
4. Retain enough source history for retries and operational recovery.

Workload: 35,000 reads/s, 12,000 writes/s, 1800 B records, 200 ms read p99 target. These are exercise assumptions; the Solution includes capacity formulas.

Snapshot copying must retain per-key versions and tombstones while the source remains the sole writer. The final fence drains admitted writes before establishing a replay barrier. Directory ownership changes conditionally, and destination activation requires the committed new epoch; routers alone cannot prevent split ownership.

Key K is deleted during the copy, and a delayed snapshot record for K later arrives. Its older version cannot resurrect K. After source fencing, the destination replays through the final barrier before activation. A stale router reaching the source receives retry/redirect rather than a successful old-epoch write.