Question presented to candidate: "You have a consistent hashing ring for a cache or a key-value store. Explain virtual nodes: what problem they solve, how many you would use, and in which situations you would or would not bother with them."
What a strong answer should cover:
- The problem: with one token per server, the ring arcs are random and very unequal, so load is uneven and a failed server dumps all its keys on one neighbour
- Virtual nodes: each physical server gets many tokens; its share is the sum of many small arcs, so imbalance shrinks roughly with the square root of the token count
- Second benefit: a failed or joining server exchanges data with many peers in parallel, not one
- Third benefit: weighting heterogeneous servers by giving bigger machines more tokens
- Costs: a bigger routing table, more ranges to stream and repair, and in replicated stores more node pairs sharing data; a real data point such as Cassandra lowering
num_tokensfrom 256 to 16 in 4.0 with a smarter token allocator - When you do not need them: fixed logical partitions, rendezvous hashing, or a static set of identical servers
Clarifying questions expected:
- How many servers, and do they differ in size?
- Is this a cache (movement costs misses) or a replicated store (movement costs streaming and repair)?
Code / implementation expected: Optional โ a ring with N tokens per server and the measured imbalance; the example runs 1 to 1000 vnodes.