What you are looking at

Two hundred cache keys — sessions, carts, product IDs — are hashed onto a circle that stands for the 32-bit hash space. Requests leave the centre, find their key and travel to the cache node that owns it. The side panel counts what matters in production: how many keys change owner when the cluster changes, how evenly the load is spread, and the cache hit rate, because every key that moves is a miss that falls through to the database.

Why hash % N hurts

hash(key) % N spreads keys well, but N is part of the formula: go from four to five nodes and roughly four out of five keys land on a different node. In a cache that means a sudden wave of misses — a self-inflicted thundering herd on whatever sits behind it. The “moved” bars run every change through all three mappings at once, so you can compare them on exactly the same event.

Rings and virtual nodes

Consistent hashing puts nodes on the same ring as the keys; a key belongs to the first node clockwise. Adding a node only takes over the arc just before it, so about 1/N of the keys move — the theoretical minimum. With a single point per node, though, arc lengths are random and one node can own far more than its share. Virtual nodes give every server many points on the ring, which smooths the load and makes a removed node's keys spread across all the survivors instead of dumping on one neighbour. This is the idea behind Dynamo-style stores, Cassandra token ranges and most memcached client libraries.

What hashing cannot fix is a single celebrity key: all requests for one key go to one node, however the ring is cut. That needs a different tool — replicating hot keys, a small local cache in front, or splitting the key itself.