Skip to main content
As our user base grows, our four shards (shard 0 through shard 3) are starting to reach capacity. Lina’s data lives on a dedicated shard outside the normal sharding rule, and now we want to add one more shard to serve regular users. At first this looks simple: add the new shard and change our routing formula. Our current rule is:
  • Hash the user ID.
  • Divide by 4 (the number of shards).
  • Use the remainder as the shard number.
With four shards the remainder can be 0, 1, 2, or 3. But as soon as we add a fifth shard and change the formula to divide by 5, the shard assignments for many users change. For a small example with just 20 users, switching from modulo-4 routing to modulo-5 can force many users to be reassigned. In one calculation, 16 of the 20 users (80%) needed to move. This movement of data between machines when you add or remove shards is called resharding. Why does adding one shard move so much data? Because the number of shards is embedded directly in the mapping rule. Changing that number changes results for nearly every input. A better routing rule avoids embedding the current shard count directly into the mapping. A widely used solution is consistent hashing.

​
How consistent hashing works

The core idea:
  • Consider the full range of hash values produced by the hash function.
  • Lay these hash values out in order, then bend that line into a circle so the maximum wraps back to the minimum — this is the hash ring.
  • Place shard “points” on the ring (each point identifies a shard).
  • To route a user: hash the user ID, locate that position on the ring, then move clockwise until you hit the first shard point — that shard owns the user.
A simple ASCII representation of the full hash space:
Because the ring contains the entire hash space, any user hash will land somewhere on the ring. From that point we move clockwise to the first shard position and assign the user to that shard. For example, if Chris’s hash lands at a point whose first clockwise shard is shard 3, Chris belongs to shard 3. If Leo’s hash lands at a point whose first clockwise shard is shard 0, Leo belongs to shard 0.
A diagram titled "Consistent Hashing" showing a circular hash ring with multiple shard nodes placed around it. Two user icons (Leo and Chris) with numeric hashes are mapped by dotted lines to points on the ring indicating which shard each user hashes to.
When we add a new shard and place it at some point on the ring (for example between shard 1 and shard 2), only the users whose hashes fall between the new shard and the previous shard clockwise are reassigned to the new shard. Users whose first clockwise shard remains unchanged do not move. This dramatically reduces the amount of resharding required when adding or removing nodes. Removing a shard works in reverse: only the keys assigned to the removed shard are reassigned (they move clockwise to the next shard). So consistent hashing solves the primary problem: it minimizes data movement when cluster topology changes.

​
The imbalance problem with single positions

If each physical shard is represented only once on the ring, some shards can end up owning very large contiguous sections while others own small ones. That leads to uneven load and storage distribution. If a heavily-loaded shard fails, its contiguous section transfers to a single neighbor — which can overload that neighbor.
A dark-themed diagram of a consistent hashing ring with labeled nodes (Shard 0–3 and a New Shard) around the circle. A highlighted "large section" and arrows show reassignment/data movement between shards when the new shard is added.

​
Virtual nodes (vnodes): even distribution and resilience

The standard mitigation is to place multiple logical positions for each physical shard on the ring — commonly called virtual nodes or vnodes. For example, shard 0 might appear at 10 different points on the ring, shard 1 at 10 different points, and so on. Important: these are not multiple machines — they are multiple logical positions that map back to the same physical shard. By spreading a shard’s positions around the ring, each physical shard ends up owning many small sections instead of one large contiguous section. This evens out the distribution of keys and reduces hotspots. When a shard fails, its many small sections are redistributed across several other shards instead of being absorbed entirely by one neighbor. When adding a new shard, the new shard receives many small sections taken from many different existing shards, which smooths the transition.
A black-background diagram titled "Consistent Hashing" showing a circular ring of multicolored dots representing hashed keys or virtual nodes. To the right is a legend of colored database icons labeled Shard 0, Shard 1, Shard 2, Shard 3, New Shard, and One More.
Virtual nodes are a practical and widely used technique to produce an even key distribution and to reduce the impact of node churn. The number of virtual nodes per physical shard is tunable — increasing it typically reduces variance but raises metadata and lookup overhead.
Choosing too few virtual nodes can leave you with high variance; choosing too many increases lookup cost and memory for metadata. Benchmark different vnode counts with your workload and monitor the variance in shard size and request load.

​
Comparison: modulo sharding vs consistent hashing

​
When to use consistent hashing

  • You expect to add or remove shards frequently (autoscaling, cloud instances).
  • You need low data movement and minimal rebalancing during topology changes.
  • You require better failure isolation and even load distribution — especially when combined with virtual nodes.

​
Summary

  • Modulo-based sharding ties routing to the number of shards and causes massive reshuffles when that number changes.
  • Consistent hashing removes the shard count from the routing decision, so adding or removing a shard only affects keys in a small portion of the ring.
  • Virtual nodes per physical shard even out load, reduce hotspots, and make node churn less disruptive.
Further reading and references:
  • Consistent hashing — Wikipedia
  • Dynamo paper (Amazon): Dynamo: Amazon’s Highly Available Key-value Store — presents consistent hashing and vnodes in a distributed storage context.

Watch Video