Consistent Hashing medium
You have a mix of fast (SSD) and slow (HDD) servers. How do you bias the Consistent Hashing ring to favor SSDs?
- A Manually assigning the high-performance SSD servers lower Hash IDs to ensure they appear first on the sorted ring.
- B Initializing a separate, dedicated hash ring specifically for SSD nodes to isolate their traffic from the HDD nodes.
- C It is not technically possible to bias the ring; hashing is inherently uniform and treats all physical hardware as equal.
- D Assigning the SSD servers a significantly larger number of Virtual Nodes (Tokens) to increase their coverage of the ring.
Answer: D. Assigning the SSD servers a significantly larger number of Virtual Nodes (Tokens) to increase their coverage of the ring.
Consistent Hashing naturally supports heterogeneous hardware via VNode weighting. If an SSD server has 10x the I/O capacity of an HDD server, you can assign it 10x the number of tokens. This increases the probability that any given key will hash into a range owned by the SSD server, effectively biasing the load without changing the underlying mathematical model.
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?