Consistent Hashing easy
If you reside a cluster from 10 to 11 nodes using Modulo Hashing, what happens?
- A The cluster achieves a perfect balance where only exactly 10% of the existing keys are required to move to new locations.
- B The mapping remains stable and nothing moves until a new write operation explicitly targets a previously stored key.
- C The vast majority of keys (~90%) map to entirely new server indices, causing a massive, cluster-wide cache stampede.
- D The system enters a read-only state and rejects new keys until a manual administrative re-sharding process is completed.
Answer: C. The vast majority of keys (~90%) map to entirely new server indices, causing a massive, cluster-wide cache stampede.
Modulo hashing (key % N) is highly unstable because a change in N (the divisor) changes the result for nearly every input key. In contrast, Consistent Hashing is designed so that adding a node only affects the specific keys that hash into the new node's range, leaving the other 90% of the cluster mapping untouched and caches valid.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- In a 'Smart Client' architecture (e.g., modern Cassandra drivers), how does the client find the right node?
- When a new node (Node X) joins the ring, where does it acquire its initial data from?
- Google's Maglev hashing algorithm (used in their Network Load Balancers) differs from standard Consistent Hashing rings. How does it generate the lookup table?
- Virtual Nodes improve balance but increase metadata size (Memory). How does 'Multi-Probe Consistent Hashing' achieve good balance without VNodes?
- In the Chord DHT protocol (a P2P consistent hashing implementation), naive lookups are O(N). How does Chord optimize this to O(log N)?
- Which of these systems is a famous user of Consistent Hashing?