Adding a Node — Minimal Disruption
Suppose we add Server D at position 30 on the ring.
Before Server D existed, keys in the range 11–50 all mapped to Server B. Now, Server D sits at 30, splitting that range:
- Keys in positions 11–30 → now owned by Server D (moved from B to D)
- Keys in positions 31–50 → still owned by Server B (untouched)
- Keys owned by Server A and Server C → completely untouched
Only the keys in the arc immediately counter-clockwise of Server D's new position need to be migrated. When adding the Nth node to a cluster of N−1 nodes, you move exactly 1/N of all keys — the theoretical minimum possible.
Before: [A:10] -------- [B:50] -------- [C:90]
After: [A:10] -- [D:30] -- [B:50] ---- [C:90]
Keys at 11–30: migrate from B → D
Keys at 31–50: stay at B
Keys at 51–90: stay at C
Keys at 91–10: stay at A
Removing a Node — Automatic Failover
If Server B crashes (position 50), the keys it owned (positions 31–50) now have no server when they walk clockwise from their position. They continue past the empty spot and land on the next server: Server C at 90.
The system self-heals without any reconfiguration. No central coordinator needs to redistribute keys — the ring geometry handles it automatically. This property makes consistent hashing particularly valuable in systems that must tolerate node failures gracefully, such as distributed databases and peer-to-peer networks.
Interviewers often ask: "What is the minimum amount of data movement when adding a node to a consistent hash ring?" The answer is 1/N of total keys, where N is the new total number of nodes. This is provably optimal — you cannot do better because the new node must take responsibility for some portion of the keyspace. Contrast this with modulo hashing, where up to N/(N+1) ≈ 80–90% of keys move. Be ready to derive this from first principles: if keys are uniformly distributed and the new node takes 1/N of the ring, it captures 1/N of the keys.