Consistent hashing is one of those ideas that sounds complicated until you see the picture — then it’s obvious, beautiful, and you wonder how anything worked before it.
The Problem
Imagine you have 4 cache servers and you want to distribute keys across them. The naive approach is hash(key) % N. This works until you add or remove a server — then N changes and almost every key maps to a different server, causing a cache miss avalanche.
- Changing N re-maps almost every key
- Adding one server triggers a cache-miss avalanche
- Scaling means a full, expensive rehash
- Only ~1/N of keys move when N changes
- New servers slot in between existing neighbors
- Scaling stays cheap and incremental
The Ring
Consistent hashing places both servers and keys on a conceptual ring of integers from 0 to 2³². A key is owned by the first server you encounter going clockwise from the key’s hash position.
When you add a server, only the keys between the new server and its predecessor need to move. When you remove a server, its keys migrate to its successor. In both cases, only 1/N of keys are affected instead of all of them.
Virtual Nodes
Real implementations use virtual nodes — each physical server gets many positions on the ring. This gives much more even load distribution when servers have different capacities.
This pattern is used verbatim (or very close to it) in production Redis Cluster, Cassandra’s token-aware routing, and every CDN edge node assignment system.
Try It
Experiment with the ring below. Add and remove servers to watch keys migrate. Increase virtual nodes to see load balance improve.
Each server is copied to 1 spot around the ring. More copies → smoother, more even load.
No keys yet. Add a few to see how evenly they spread across servers.
To find where a key lives: hash the key to a point on the ring, then walk clockwise until you hit the first server position. That server owns the key. Removing a server simply hands its slice to the next server clockwise; adding one carves a new slice out of a single neighbor. No global reshuffle — just one boundary moves.
Why This Matters
Without consistent hashing, scaling a distributed cache or database means a full rehash — every key moves to a new server. With consistent hashing, you get O(K/N) key movements when adding or removing a node, where K is total keys and N is the number of nodes.
That’s the difference between a 30-second operation and a multi-hour migration event.
Discussion
Sign in to join the conversation.