Consistent Hashing hard
In Dynamo's ring, if the Preference List nodes [A, B, C] are all down, the system might write to Node D (which is not in the list). This is called:
- A Sloppy Quorum.
- B Strict Quorum.
- C Zombie Write.
- D Ghost Write.
Answer: A. Sloppy Quorum.
In high-availability systems like DynamoDB, 'Sloppy Quorum' ensures that writes always succeed if *any* healthy nodes are available. If the preferred nodes on the ring are down, the write is accepted by another node and stored as a 'Hinted Handoff'. Once the original owners rejoin the cluster, the 'sloppy' node hands the data back to them, restoring the system's long-term consistency.
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?