Consistent Hashing Visualizer — Free HTML CSS JS Snippet

Consistent hashing is one of the most-referenced but least-visualized concepts in distributed systems interviews, usually summarized as "adding a node only remaps a small fraction of keys" without ever showing why. This snippet implements both consistent hashing and its naive alternative side by side, with a literal toggle between them, so the difference is something you click and watch rather than something you memorize as a bullet point.

The ring: real trigonometry, not a static image

Both servers and keys are positioned on a circle using posFor(angleDeg), which converts a 0-359 degree value into screen coordinates with x = cx + r * cos(angle) and y = cy + r * sin(angle), offset by -90 degrees so 0 degrees sits at the top of the circle and increasing angle moves clockwise. Every server and key gets its angle from hashString(name) % 360, a small deterministic hash (a running h = h * 31 + charCode accumulator, the same multiply-and-add shape as Java's String.hashCode) applied to its name string. Because the hash is deterministic, the same server or key name always lands at the same point on the ring across every render, which is exactly the property real consistent hashing depends on.

Consistent hashing: owner is "next server clockwise"

computeAssignment() in consistent mode does exactly one thing per key: it walks the currently active servers, sorted by angle, and finds the first one whose angle is greater than or equal to the key's angle — that server owns the key. If no server has a larger angle (the key is past the last server going clockwise), ownership wraps around to the server with the smallest angle, which is what makes the ring a ring instead of a line. This lookup is the entire algorithm; there is no separate rebalancing step, no explicit "move this key" logic — ownership is simply a function of where servers currently sit on the circle.

Why only nearby keys move when a server is added or removed

The critical property becomes visible in recompute(): it snapshots the previous key-to-server assignment map, recomputes a fresh one after a server is added or removed, and diffs the two, animating (a color flash plus a brief scale pulse) only the keys whose owner actually changed. When a new server is inserted at some angle X, it can only ever "steal" keys that fall between X and the previous owner going counter-clockwise from X — every key elsewhere on the ring still finds the same next-clockwise server it always did, because nothing about the ring changed at their position. Removing a server works the same way in reverse: only the keys that server owned get reassigned, to its clockwise neighbor, and every other key's nearest-clockwise-server lookup is completely unaffected. Click Add Server or Remove Server with the demo running and watch most key-to-server lines stay exactly where they are — only a small cluster near the changed node flashes and reroutes.

Naive mod-N: why almost everything moves

Toggling "Naive mod-N hashing" switches computeAssignment() to a completely different rule: owner = activeServers[hash(key) % N], where N is simply how many servers are currently active. This is the modulo-based sharding scheme many systems reach for instinctively — and its flaw is arithmetic, not incidental. Changing N by adding or removing one server changes the divisor in every single key's hash % N computation, and because the modulo operation has no relationship to the previous mapping, the vast majority of keys land on a completely different index than before, even though only one server was added or removed. With the naive toggle on, clicking Add Server or Remove Server causes nearly every line on the ring to flash and swing to a new server simultaneously — this snippet doesn't just claim that happens, the exact same diff-and-animate logic used for consistent hashing proves it happens, because it is measuring real reassignment counts from real modulo arithmetic, not a scripted animation.

Why this matters for caches and databases

A cache or database shard that uses naive mod-N hashing effectively invalidates almost its entire cache (or forces almost every key to migrate) every time capacity is scaled up or down — exactly when a system is under the most load and can least afford it. Consistent hashing keeps that migration proportional to the size of the change instead of the size of the whole cluster, which is why it underlies real systems like Amazon DynamoDB, Apache Cassandra, and most CDN and cache-sharding layers. The "Keys reassigned last change" stat in this snippet is the same number a real capacity-planning engineer cares about when deciding whether scaling an event will cause a stampede of cache misses.