Consistent Hashing Visualizer

The naive way to spread keys across N servers is hash(key) mod N, and it breaks the moment N changes. Add or remove one server and the remainder shifts for almost every key, so nearly the whole dataset moves. Consistent hashing fixes that by putting servers and keys on the same ring, so a membership change only disturbs the arcs next to the change.

What it computes

pos(label) = FNV-1a 32-bit hash(label) / 2^32       a point in [0, 1)
vnodes(s)  = labels s#0, s#1, … s#(v − 1)
owner(key) = first vnode with pos ≥ pos(key), else wrap to the lowest vnode
load(s)    = keys owned by s / total keys
moved      = keys whose owner changed after an action

• Position 0 is 12 o’clock and positions increase clockwise, so 0.25 is 3 o’clock.
• Each server s appears v times, once per virtual node, with v set by the slider from 1 to 20.
• A vnode owns the arc from the previous vnode, exclusive, up to itself, inclusive. The colored arcs on the ring draw exactly those slices.
• Every add, remove or slider change snapshots each key’s owner, applies the change, and reports how many keys now have a different owner.

A worked example

The default ring has servers A, B and C with 3 virtual nodes each, and 10 keys. The nine vnodes hash to these positions:

1. user:42 hashes to 0.1852 and session:x9 to 0.1134. Walking clockwise, the first vnode either meets is A#1 at 0.3260, so both belong to A.
2. Seven keys sit between 0.51 and 0.94, past A’s last vnode at 0.3377. No vnode lies ahead of them, so they wrap round to the lowest vnode, B#2 at 0.0123. doc:alpha at 0.0111 reaches B#2 directly. B ends up with 8 keys.
3. C’s arc runs only from 0.0240 to 0.1000, and no key lands in it.
4. Press Add node: D’s vnodes land at 0.9519, 0.9558 and 0.9597, inside B’s long wrapping arc. The status line reads Added node D · 7 of 10 keys moved. All seven went from B to D, and A’s two keys did not move.

That last step shows the property that matters: keys only move to the newcomer. Using the same hash with plain modulo, going from mod 3 to mod 4 would change the owner of 9 of these 10 keys.

Assumptions and limits

• A simple hash, visibly lumpy. FNV-1a maps labels that differ only in their last character to points less than 1% of the ring apart, so each server’s vnodes bunch together. Raising the slider therefore smooths load much less here than it would with a well-mixed hash such as MurmurHash3, which production rings use.
• Ten keys is a tiny sample. Load percentages jump in steps of 10%. With millions of keys, load tracks each server’s share of the ring.
• Ownership only. There is no replication to the next nodes clockwise, no weighting for bigger servers and no data transfer cost.
• Removal is last-in, first-out. Remove node takes away the most recently added server.

How to use the result

• Read the moved count as the cost of a change. Each moved key is a cache miss or a record to copy. A good ring keeps it near one node’s share.
• Look at ring share, not key count, for balance. With few keys the bars are noisy; the arc lengths show where load will settle.
• Give every server many well-spread points. Real deployments use tens to hundreds of virtual nodes per server, or weight the count by capacity, so arcs average out and a failure spreads its keys across many survivors.
• Pick a strong hash. The lumpy default here is the lesson: placement quality depends on how well the hash mixes similar labels.

When to use it, and when not

Use consistent hashing when the set of servers changes while keys must stay findable: cache fleets that scale with traffic, partitioned stores that add nodes, and clients that route requests without asking a directory. What you buy is a small moved count, about one node’s share of the keys per change instead of nearly all of them.

Skip it when the server count is fixed for the life of the data: plain modulo is simpler, and with a good hash it balances evenly. Skip it when queries scan ranges, because hashing scatters neighbouring keys, so “all orders from last week” touches every node; range partitioning keeps sorted keys together. And no placement scheme helps a single hot key. Every request for it lands on the same owner.

Trade-offs and limits

Virtual nodes trade memory for balance, and only pay off with a hash that mixes well. In this tool, raising the slider from 3 to 20 changes B’s share of the ring from 68.6% to 71.8%. Balance gets worse, because FNV-1a keeps each server’s labels clustered however many there are.

Common mistakes

• Replicating to the next vnodes instead of the next servers. In the default ring the two points after A#1 at 0.3260 are A#0 and A#2, so three “replicas” would all live on server A. Walk clockwise and skip points whose server you already have, as Dynamo’s preference list does.
• Clients that disagree on membership. A client that still sees A, B and C and one that already sees D route 7 of the 10 keys to different owners. Every router needs the same server list, from one source.
• Changing the label format or the hash. Every position moves. Renaming the labels here from A#0 to node-A#0 changes the owner of all 10 keys, as bad as switching from mod 3 to mod 4.
• Balancing key counts, not load. Equal keys per server can still mean unequal bytes or requests. Watch bytes and request rate per server, and handle hot keys separately, for example by caching them on every node.
• Too few points per server. A failed server’s whole arc goes to its clockwise neighbour. Remove C here and all of its 7.6% lands on A, which jumps from 23.8% to 31.4% of the ring.

Check yourself