Modulo placement assigns a key to a server with hash(key) % N, where N is the number of servers. The divisor is part of the mapping, so when N changes, most keys are assigned to a different server. Consistent hashing removes that dependency. It places keys and servers on the same circular hash space, so adding or removing a server moves only the keys in the arcs next to that server. It improves placement stability, but it does not by itself make storage or request load even.
Why modulo placement breaks when N changes
Modulo hashing is simple and works well while the server list is fixed. The trouble starts on resize. Take a hash value of 19 and a fixed set of keys. With four servers, the key goes to server 3 (19 mod 4). With five servers, it goes to server 4 (19 mod 5). The key moved even though nothing about the key changed.
As an Amazon Associate I earn from qualifying purchases.
Across uniformly distributed hash values, going from 4 to 5 servers keeps a key in place only when both remainders match. Checking the 20 residues of the combined cycle, they match for only 4 (0, 1, 2 and 3), so about 20% of keys stay put and about 80% move. This is arithmetic on an idealized uniform hash, not a benchmark of any particular system.
Apache Cassandra’s documentation uses a 100-bucket version of the same argument and states the consequence directly: “In this naive scheme, however, adding a single node might invalidate almost all of the mappings.” For a cache or a sharded store, that means a resize turns into a mass data migration or a wave of cache misses.
#1 Best Overall
- color: White
- INTRODUCTION TO ALGORITHMS, FOURTH EDITION
How a hash ring assigns keys
A consistent-hashing ring maps both keys and node positions, called tokens, into one circular, ordered space. To find the owner of a key, hash the key to a position and walk clockwise until you reach the first node token. That node owns the arc between its predecessor’s token and its own token.
The useful property is what happens on membership change. Only the arcs touched by the change are reassigned.
Adding a node
- The new node inserts its token(s) into the ring.
- It takes ownership of the arc from its own token back to the previous token, which was previously owned by its successor.
- Keys in every other arc keep their owner.
Removing a node
- The departing node’s tokens leave the ring.
- Its arcs pass to the next node clockwise.
- No other ownership changes.
The phrase to use is “only affected ranges move,” not “nothing moves.” Data still has to be copied to the new owner, but the amount is proportional to the arc that changed hands rather than to the whole keyspace.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Replicas: walking to distinct nodes
Ownership and replication are separate decisions. The primary owner is the first node clockwise from the key. Replicas are chosen by continuing to walk the ring until the required number of distinct physical nodes has been collected. Cassandra’s documentation illustrates this with eight nodes and a replication factor of three: the replicas for a key are the three distinct nodes found clockwise from its position.
The word “distinct” matters. If a physical machine owns several tokens, the walk must skip the extra tokens it encounters, or two replicas would land on the same machine.
Why a ring is not automatically balanced
A ring limits how much moves. It does not guarantee that each node receives an equal share. Those are different properties, and most confusion about consistent hashing comes from treating them as one.
Rank #4
Few tokens per node
With one token per physical node and a small cluster, the arcs can be very unequal. Adding a node splits one arc, but the split may not produce a useful balance. Cassandra’s documentation describes this limitation and notes that uneven token ranges can produce uneven request load.
Virtual nodes
Virtual nodes give each physical machine several ring positions. Its ranges are scattered around the ring rather than forming one contiguous arc. The Dynamo design paper describes this approach: when a node fails, its virtual ranges are taken over by several other nodes, so the effect is spread out. A capacity addition can also take portions from multiple existing owners instead of one.
Best Value
Virtual nodes are a trade-off. More tokens sample the ring more finely, but each token adds routing and metadata state that the cluster must track and keep consistent.
The token count is version-specific. Cassandra’s current documentation says that in Cassandra 2.x the only token-allocation algorithm was random token selection, and the default number of tokens per node had to be quite high to maintain balance, set to 256. That is historical configuration, not a universal recommendation. Check the configuration reference for your release before copying a value.
Hot keys
Equal key counts do not mean equal work. A single popular key can generate a hot partition no matter how evenly the ring is divided, because the load follows request popularity, not key count. Virtual nodes do not address this. Remedies such as splitting hot keys or adding caching or replication for them are workload-level decisions that sit outside the hashing scheme.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteBounded-load consistent hashing
Bounded-load consistent hashing is one distinct response to imbalance. It keeps the ring but caps how much load any server may accept. When the nearest server is at its cap, the item moves on to the next server clockwise. The 2016 arXiv paper Consistent Hashing with Bounded Loads analyzes this method. In its formal model with n clients and n servers, it reports a maximum load of 2 and an expected constant number of clients moving per update.
Those results hold within the paper’s model and its definition of load. They are not a blanket production guarantee for any particular database or cache. The paper is a formal alternative, not evidence that the method is universally deployed or always the right choice.
Quick Recap
Choosing between the approaches
| Approach | Keys moved on membership change | Balance behavior | Load bound | Main cost |
|---|---|---|---|---|
Modulo (hash % N) |
Most keys, because the divisor changes; Cassandra docs say adding one node may invalidate almost all mappings | Even only while N is fixed | None stated | Simple, but a resize forces a broad remap |
| Basic ring, one token per node | Only the arcs adjacent to the changed node | Can be uneven with few nodes | None (no hard bound) | Simple ring, weak balance at small scale |
| Ring with virtual nodes | Only affected ranges, spread across several existing owners | Improved sampling of the ring; depends on token count and allocation | None stated in the cited Cassandra and Dynamo sources | More tokens, more routing and metadata state |
| Bounded-load ring | Constant expected client movement per update, in the 2016 paper’s formal model | Each server capped at a load limit | Maximum load 2 with n clients and n servers, in the formal model | Capacity bookkeeping; production cost not stated |
Practical checks before adopting a ring
- Measure how many keys move on a resize in a staging copy of your system. Compare the result with the roughly 80% figure for modulo at 4-to-5 servers.
- Check token ranges or shard sizes per node, not only the total key count.
- Measure request load per key or partition, since popularity can dominate placement.
- Confirm your system’s token-count and allocation defaults against its documentation for your exact version.
- Decide whether you need a hard load cap. If you do, evaluate bounded-load variants and their implementation support rather than assuming a ring provides one.
“
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
