Consistent Hashing easy
What is the primary risk of using Consistent Hashing without 'Virtual Nodes'?
- A Significant degradation in lookup performance, causing average request latency to scale linearly with cluster size (O(N)).
- B Total data loss occurring during a network partition because the ring cannot maintain a consistent quorum state.
- C Uneven data distribution, where random node placement leads to some nodes owning much larger ring segments than others.
- D Incompatibility with standard security protocols like SSL/TLS, making the cluster vulnerable to man-in-the-middle attacks.
Answer: C. Uneven data distribution, where random node placement leads to some nodes owning much larger ring segments than others.
When physical nodes are hashed onto a ring, they likely won't be perfectly spaced (e.g., at 120, 240, 360 degrees). Simple random placement often results in 'clusters' of nodes and large empty gaps on the ring, leading to some servers being massively overloaded while others are mostly idle. This is solved by using Virtual Nodes.
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?