Consistent Hashing Visualizer
An interactive consistent-hashing playground. Add and remove nodes, tune virtual nodes, and watch keys remap around the ring in real time — see exactly why consistent hashing moves only K/N keys instead of reshuffling everything, and how virtual nodes smooth out hotspots.
How it works
- Each node and each key is hashed onto a circle of 0 … 2³²−1.
- A key belongs to the first node clockwise from it.
- Adding a node only steals the keys in its new arc — the rest never move.
- Virtual nodes spread one physical server across many ring positions to even out load.
Frequently asked questions
What is consistent hashing?
Consistent hashing maps both servers and keys onto the same circular hash space (the "ring"). Each key is owned by the first server found clockwise from the key. When a server is added or removed, only the keys between it and its neighbour move — on average K/N keys for K keys and N servers — instead of remapping every key the way plain modulo hashing would.
Why are virtual nodes used?
With only one point per server, the ring is uneven and some servers own a much larger arc (and more keys) than others. Virtual nodes place each physical server at many points around the ring, so the arcs average out and load is distributed evenly. More virtual nodes means smoother balance at the cost of more metadata.
How many keys move when a node is added?
On average K/N keys, where K is the total number of keys and N is the number of nodes. Only the keys that fall in the arc the new node now owns are remapped; every other key stays exactly where it was. This is the core advantage over modulo hashing, where adding a node remaps nearly every key.
Where is consistent hashing used in practice?
It is the backbone of distributed caches (Memcached clients, Redis Cluster), key-value stores (Amazon DynamoDB, Apache Cassandra, Riak), CDNs, and load balancers — anywhere you need to spread data across a changing set of nodes with minimal disruption when the set changes.