# Exercise 3 (Hardest): Plan a Resharding Migration

## Scenario

`InvoiceRail`, a B2B invoicing platform, currently shards its `invoices` table across 4 shards using plain `hash(company_id) % 4`. The platform has grown and needs to move to 8 shards to relieve sustained CPU pressure across all 4 existing shards (this is a genuine capacity problem, not a hotspot on one shard — load is even across the current 4, all 4 are just individually overloaded).

Constraints the team has stated:
- The migration must not require platform-wide downtime — `InvoiceRail` has customers in every timezone, so there is no acceptable maintenance window.
- The current scheme is plain `hash(company_id) % 4`, exactly the naive scheme theory (Part 2) section 1 warns changes the target shard for almost every key when `N` changes.
- The team has never implemented consistent hashing before and is asking you to plan the migration as a one-time event to fix the immediate capacity problem, while also setting the scheme up so this doesn't have to be a from-scratch crisis again next time.

## Deliverables

1. **Explain precisely what would go wrong** if the team simply changed the modulo from `% 4` to `% 8` in application code and redeployed, using theory (Part 2) section 1 — be specific about what "the target shard for almost every key changes" means operationally (what happens to a request for `company_id=X` that arrives one second after the redeploy, before any data has actually moved?).
2. **Propose adopting consistent hashing as part of this migration**, using theory (Part 2) section 2 — describe, at a conceptual level, how introducing a hash ring with 8 shard positions instead of a plain `% 8` changes how much data actually needs to move compared to the naive approach, and why that directly serves the "no downtime" constraint (less data movement -> shorter window where any given key's location is in flux).
3. **Describe a live-migration sequence** for moving one range/arc of keys from an existing shard to a new shard without downtime — at minimum, address: how does the system serve reads/writes for a key *during* the window where its data is being copied from the old shard to the new one, and how does the routing layer know when it's safe to switch to treating the new shard as authoritative for that key?
4. **Explain the operational payoff** the team asked for — why does building this out with consistent hashing now mean the *next* capacity expansion (e.g. 8 shards to 12) is a smaller, routine operation instead of another full crisis, tying back to theory (Part 2) section 2's point about only the affected ring arc moving.

## Constraints

- Your answer must not assume a maintenance window or accept any period where `invoices` writes are rejected platform-wide — that directly contradicts the stated constraint.
- Do not hand-wave the "during migration, which shard is authoritative for a given key" question — theory (Part 2) section 4's mitigation of a hot key still applies here (a key mid-migration is a small-scale version of "where does this key's traffic go right now"), and a real answer needs a real mechanism (e.g. dual-write with a cutover marker, or an explicit in-flight/migrating state in the shard map), not just "it copies over."