What it's for
- The caching chapter assumed the fleet was fixed. Real fleets aren't: servers die, get replaced, get added for the holidays. With hash(key) mod N, every change of N remaps almost every key — a cache that forgets everything exactly when it's least convenient.
- Consistent hashing makes membership changes cheap: keys and servers share one ring, each key belongs to the next server clockwise, and adding or removing a server moves only that server's slice — about 1/N of the keys, not all of them.
Good to know
The ring shown is the classic ring/successor scheme — one member of the consistent-hashing family, with rendezvous (HRW) and jump hash as siblings that share the goal with different mechanics. Hash the servers onto a logical circle (angle is not geography — a position, not a place), hash each key onto the same circle, and walk clockwise to the first server: here, ownership is the first node at an angle greater than or equal to the key's, wrapping past the end to the first node, and a key landing exactly on a node belongs to it — the toy's declared tie rule. The toy's hash is each key's declared position, so both schemes — ring and the mod-N baseline — map the same twenty keys, and every moved-key count shown is recomputed from that actual mapping, not assumed. When a server leaves, only the keys between it and its predecessor move — to its successor — and when one joins, it takes a slice from its successor. Everyone else's keys stay put, which is what "consistent" buys: minimal reshuffling, not zero. One honest flaw: three random server positions give three uneven slices, and an uneven ring is a hot shard by another name. The fix is virtual nodes — each server claims many small spots on the ring instead of one, so the law of large numbers evens the slices out; the toy shows the jump from 3 spots to 12. Spots, not machines: virtual nodes are extra positions for the same hardware, and they even out key counts, not popularity — a hot key still lands on one spot, the sharding chapter's celebrity in a new costume. The same idea travels far beyond caches: it's how Dynamo-style databases decide which node owns a row, tying this part's caching, sharding and replication chapters into one picture. It isn't free — you still need replication for durability (a ring alone loses the dead server's slice), lookups cost a hop of routing metadata, and weighted or bounded-load variants exist for fleets that aren't uniform. And the ring changes ownership on paper only: actually moving the bytes, teaching every client the new map and surviving the window where two maps disagree is a separate protocol — routing metadata, data transfer, concurrent traffic — which this toy deliberately omits.
How it works, step by step
Why the steps go in this order
- The naive scheme comes first: mod-N is what everyone reaches for, and its failure is the entire motivation.
- The failure is shown before the fix: watching fourteen of twenty keys move makes "only a slice moves" mean something.
- The ring is drawn before any rule, because the rule — walk clockwise — only makes sense on the picture.
- Removal before addition: losing a server is the scary case; adding is the same movie played kindly.
- Virtual nodes come last: they're the patch on the scheme's one visible flaw, not part of the core idea.
Before you rely on it
This is a toy: twenty hand-placed keys, three servers, one ring. the moved-key counts (10 of 20, 7 of 20, 4 of 20, 16 of 20) are recomputed from the toy's declared mapping — about 1/N of the key space per change is an expectation under even-hash assumptions, not exact for twenty keys, and real distributions still skew. The ring says nothing about durability: when a cache server dies its slice is simply cold until refilled, and when a database node dies you need the replication chapter, not just the ring. The cited sources describe production systems with their own measured behavior.