Virtual Nodes in Consistent Hashing: The Detail That Wins the Follow-up

Most candidates can draw a hash ring: hash servers onto a circle, hash each key, walk clockwise to the first server. Interviewers then ask the real question: "Is the load balanced?" With only a handful of physical servers, it usually isn't.

Why a plain ring is lumpy

With N servers placed at N random points, the arc each server owns varies a lot. For small N, the largest arc is often two to three times the average, so one machine receives far more keys and traffic than the others. When a server leaves, its entire arc falls onto a single neighbour, which can cascade.

The fix: many points per server

Give every physical server V positions on the ring (hash server_id#0, server_id#1, ...). Each physical server now owns many small arcs scattered around the circle. By the law of large numbers its total share converges toward 1/N, and when it leaves, its small arcs are spread across many different neighbours instead of one.

Bonus: heterogeneous hardware

Virtual nodes also give you weighting for free. A machine with twice the memory gets twice as many vnodes. Mentioning this shows you're thinking about real fleets, not textbook ones.

Choosing V

Trade-offs to volunteer

  1. Rebalancing granularity: moving a vnode moves a small slice of data, which makes scaling smoother.
  2. Replica placement: when choosing the next R distinct servers clockwise, skip vnodes that belong to a server you've already picked, or replicas can end up on the same machine.
  3. Alternatives: rendezvous (highest random weight) hashing and jump consistent hash achieve balance without a ring; know one sentence about each.

The one-line summary for the interviewer: "Consistent hashing limits how many keys move; virtual nodes make sure the keys that stay are evenly spread."


Disclosure: I work on Linkjob.ai, an AI interview assistant. These notes are general study material.