Consistent hashing is a technique for distributing keys across a changing set of nodes — servers, cache instances, or database shards — while minimizing how many keys have to move when a node is added or removed. It solves a problem that plain hashing handles badly: at any real scale, nodes fail, get replaced, and get added for capacity, and a naive hashing scheme can turn a routine scaling event into a near-total cache invalidation.
What changed in 2026
- Virtual nodes remain the default implementation across major systems, but tooling for visualizing and tuning ring balance has become more accessible in managed database consoles.
- Rendezvous hashing (highest random weight) gained more attention as a simpler alternative that avoids maintaining an explicit ring, trading some computational cost for a smaller, easier-to-reason-about implementation.
- More load balancers and service meshes now expose consistent hashing as a built-in routing policy, rather than something teams had to implement themselves, for use cases like session affinity and cache-friendly routing.
Why plain hashing falls apart at scale
The naive approach to distributing keys across N nodes is hash(key) % N. It works fine — until N changes. Adding or removing even one node changes the modulo for almost every key, which means almost every key now maps to a different node. For a cache, that is effectively a full cache wipe. For a sharded database, that means a massive, synchronized data migration triggered by a routine capacity change.
How the hash ring works
Consistent hashing arranges both nodes and keys on a conceptual ring of hash values (commonly 0 to 2^32-1). Each node is placed on the ring by hashing its identifier. Each key is placed on the ring the same way, and is assigned to the first node found by moving clockwise from the key's position.
ring positions (0-100 for simplicity):
node A -> 12
node B -> 47
node C -> 81
key "order_101" hashes to 55 -> owned by node C (next clockwise from 55 is 81)
key "order_204" hashes to 20 -> owned by node B (next clockwise from 20 is 47)
When a node is removed, only the keys that were mapped to it move — to the next node clockwise on the ring. Every other key stays exactly where it was. When a node is added, only the keys between the new node and its counter-clockwise neighbor move to it. This is the core property: node changes affect a fraction of keys proportional to 1/N, not all of them.
Virtual nodes: fixing uneven distribution
A ring with only a few real nodes tends to distribute keys unevenly — one node might end up owning a disproportionate arc of the ring just from hash randomness. The fix is virtual nodes: each real node is hashed onto the ring multiple times (often 100–200 virtual positions per physical node), so the ring ends up finely and evenly divided regardless of how few physical nodes exist.
Consistent hashing vs the alternatives
| Approach |
Keys remapped on node change |
Complexity |
Notes |
| Modulo hashing |
Nearly all keys |
Very low |
Fine only for a fixed, unchanging node count |
| Consistent hashing (ring) |
~1/N of keys |
Moderate |
Standard choice for caches and sharded stores |
| Rendezvous hashing |
~1/N of keys |
Low |
No ring to maintain; slightly more compute per lookup |
| Range-based sharding |
Only keys in the affected range |
Moderate |
Common in databases, needs rebalancing logic |
Where it is actually used
Consistent hashing underlies Memcached client libraries, DynamoDB's partitioning, Cassandra's ring architecture, many CDN request-routing layers, and load balancers doing session-affinity routing. It also pairs naturally with a bloom filter at each node — the ring decides which node owns a key, and a local bloom filter quickly rules out keys that node does not actually hold.
Common pitfalls
Skipping virtual nodes. Without them, a small cluster can end up with wildly uneven load distribution, defeating much of the benefit.
Assuming zero keys move. Consistent hashing minimizes remapping, it does not eliminate it — plan for the fraction of keys that will move on any node change.
Forgetting hot keys. Consistent hashing distributes keys evenly by hash, not by access frequency. A single very popular key can still overload the node that owns it, regardless of how well-balanced the ring is.
FAQ
Is consistent hashing only used for caching?
No — it is used anywhere keys need to be distributed across changing nodes, including database sharding, distributed load balancing, and peer-to-peer systems.
How many virtual nodes should each physical node get?
Most production systems use somewhere between 100 and 200 virtual nodes per physical node, though the right number depends on cluster size and how evenly balanced you need the ring to be.
Does consistent hashing help with an api gateway load-balancing traffic?
Yes, when session affinity or cache locality matters — the gateway can hash a client or session identifier onto the ring rather than round-robining, so repeat requests land on the same backend.
What happens if a node fails without being cleanly removed from the ring?
Its keys become unreachable until the ring is updated to route around it, which is why health checks and automatic ring updates matter alongside the hashing scheme itself — the same discipline you would want before deliberately testing failure with chaos engineering.
Where to go next