Consistent Hashing

1. What exactly is Consistent Hashing?

Your .NET backend shards data, cached records, across several Redis instances. Which instance a given key belongs to is decided by dividing a number derived from the key by the total instance count, and using the remainder to pick one.

Now the instance count changes, 4 to 5, because traffic grew. That formula's result changes for almost every key at once. Nearly the whole cache gets treated as a miss at the same moment, and everything reloads from the database simultaneously, right when that extra capacity was supposed to help, not pile on more load.

Changing the count a formula divides by remaps almost everything, not just the share that actually needed to move. That's exactly what consistent hashing avoids.

2. How would you fix it in Azure?

Consistent hashing changes how that assignment works: place both the instances and the keys on a fixed ring using a hash function, instead of picking an instance by dividing by the current instance count. Each key belongs to the next instance found going clockwise around that ring from its own position, so adding or removing an instance only changes ownership for the keys immediately next to it, every other key's assigned instance stays exactly the same.

Use: Azure Cache for Redis Clustering

Add or remove a server without a full reshuffle: only its immediate neighbors on the ring are affected.

3. How can you visualize it in everyday terms?

A coat check assigns tickets by walking down a fixed row of hooks and hanging each coat on the next hook after where the last coat landed, wrapping back to the start once it reaches the end.

Adding one more hook to that row only changes which hooks catch a couple of coats near the new one. Every other coat stays exactly where it already was.

Adding or removing one hook only ever disturbs its immediate neighbors.