Consistent Hashing
Adding a node without reshuffling the world.
Say you spread keys across servers with hash(key) mod N — divide by the number of servers, use the remainder. It works until you add a server: N changes, almost every remainder changes, and roughly 90% of all keys must move to new machines at once. For a cache, that is a total cache wipe; for a database, a data-movement disaster.
Consistent hashing fixes this by placing both servers and keys as points on a ring. Each key belongs to the first server clockwise from it. In the animation, watch the key dots roll clockwise to their nearest server dot. Then a new server joins the ring — and only the glowing arc of keys between it and its predecessor re-homes, about 1/N of the data. The side-by-side mod-N panel shows the alternative: 90% of keys chaotically reshuffling.
This is the mechanism behind Redis Cluster, Cassandra, and DynamoDB, and it also solves sticky routing — pinning each WebSocket user to the same chat server even as servers come and go.
Interview tactic: you do not derive this on the whiteboard. When asked "what happens when you add a cache node?", invoke it by name and give the ring intuition in about 30 seconds — that is exactly the expected depth.