Consistent Hashing medium
In a ring with Virtual Nodes, why is picking the 'Next N clockwise successor VNodes' as replicas dangerous?
- A Multiple VNode tokens from the same physical machine might land adjacent to each other, leading to a single point of failure.
- B The resulting replicas might be distributed too far apart across the ring, causing excessive geographic network latency.
- C It creates an infinite replication loop where nodes continuously attempt to push data to their own virtual successors.
- D The secondary system data likely becomes corrupted due to concurrent write synchronization issues on the virtual ring.
Answer: A. Multiple VNode tokens from the same physical machine might land adjacent to each other, leading to a single point of failure.
In a cluster with VNodes, one physical server owns many points on the ring. If you blindly pick the 'next 2 neighbors' for replication, there is a high statistical probability they are just other VNodes of the *same* physical server. To ensure true fault tolerance (Availability), the replication logic must skip over neighbors until it identifies the required number of *distinct* physical machine instances.
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?