Consistent hashing

You are running a cache spread across 4 servers. To decide which server holds which key, you use the obvious trick: hash the key to a number, take it mod 4, and that is the server. Key "user:42" hashes to 391, 391 mod 4 is 3, so server 3 holds it. Every client computes the same answer, no coordination needed. It works great.

Then traffic grows and you add a 5th server. Now every lookup computes mod 5 instead of mod 4, and here is the disaster: almost every key now points at a different server than before. The data did not move, but everyone is looking for it in the wrong place. Your cache goes from warm to nearly empty in an instant, and the full weight of those misses lands on the database the cache was protecting.

Consistent hashing is the fix. It is a different way of mapping keys to servers where adding or removing one server only relocates a small, fair share of the keys instead of nearly all of them. It shows up in distributed caches, in databases like Cassandra and DynamoDB, and in interviews the moment you say "I'll spread this across several nodes" and the interviewer asks "and what happens when you add one?"