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 give one physical server 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, called the ring. Each key is owned by the first server position found clockwise from the key. When a server is added or removed, only the keys in the arc it gains or gives up change owner, instead of almost every key being remapped as happens with plain modulo hashing. That makes membership changes cheap for caches and partitioned databases.
How many keys move when a node is added?
Only the keys that fall in the arcs the new node takes over, and every one of them moves to the new node; no key moves between existing nodes. With a well-balanced ring of N nodes, adding one takes about K divided by (N plus 1) of the K keys, and removing one redistributes the roughly K divided by N keys it held. Plain modulo hashing is far worse: going from hash mod 3 to hash mod 4 changes the owner of about 75% of keys.
Why are virtual nodes used?
With one point per server the arcs between points are uneven, so some servers own a much larger slice of the ring, and more keys, than others. Virtual nodes place each physical server at many points so the arc sizes average out. They also spread a failed server’s keys across many survivors instead of dumping them on one neighbor. The cost is a larger ring to store and search, which is small in practice.
Why does the ring look unbalanced in this visualizer?
The demo hashes labels such as A#0, A#1 and A#2 with 32-bit FNV-1a. Labels that differ only in their last character land within about 1% of the ring of each other with this hash, so one server’s virtual nodes bunch together instead of scattering. In the default state server B owns about 69% of the ring. Production rings use better-mixed hashes such as MurmurHash3 or xxHash, where virtual nodes spread out and balance improves as you add them.
Where is consistent hashing used in practice?
It underpins Amazon’s Dynamo design and the databases it inspired, such as Apache Cassandra and Riak, as well as client-side sharding in Memcached libraries, CDN request routing and many load balancers. Some systems use a close relative instead: Redis Cluster splits the keyspace into 16,384 fixed hash slots and assigns slots to nodes. Either way the goal is the same, spreading data across a changing set of nodes with minimal movement when the set changes.