Consistent Hashing Ring

Explore key placement when a cluster grows or shrinks. Choose 1–400 virtual tokens per node and 1,000–200,000 synthetic keys, then Show ring. Start with one token to see uneven ranges; compare 64. Add a node or remove one in the distribution table. Colors stay attached to node names. Changing tokens or sample size clears results; Reset restores all defaults.

A key belongs to the first token clockwise, including a token at exactly the same position; past the last token it wraps to the first. Each arc belongs to its ending token’s node. The table counts primary owners, not all copies or traffic. Highest load is the largest count divided by mean count; spread is population standard deviation divided by that mean. More tokens generally improve balance, without guaranteeing monotonic improvement for each finite sample.

After a membership change, compare actual moved keys with hash(key) modulo the node count, using the same full key set and stable node names before and after. Addition only moves keys to the new node; removal only moves keys previously on the removed node. The 1/n share uses the larger cluster size: an expectation for uniform placement, not a lower bound or guaranteed measured result. The expandable examples show up to eight moved keys.

Enter a key to inspect its position and distinct clockwise destinations. The replication factor 1–16 includes the primary; unavailable copies are reported instead of duplicating nodes. This browser-only teaching model uses 32-bit FNV-style mixing over JavaScript string code units plus a Murmur finalizer, not a standard interoperable byte-hash or security hash. No weights, hot-key traffic, failures, replica transfers, quorum or full Dynamo implementation. Lookup is O(log T); a distribution pass is O(K log T) after token sorting. The Dynamo paper §§4.2–4.3 supports ring ownership, virtual tokens and skipping duplicate physical nodes; its MD5 and production system are not reproduced here.