How Consistent Hashing Works (With a Real Example)

Imagine you have three cache servers and you are routing requests by doing hash(key) % 3. Works fine. Then you add a fourth server. Suddenly hash(key) % 4 gives completely different results for almost every key. Your entire cache is now invalid. Every request is a miss. Your database is taking the full load.

That is not a hypothetical. That is what happens in production when you scale a cache cluster with naive modulo hashing. Consistent hashing exists to prevent exactly this.

What Is Wrong With Regular Hashing

With regular modulo hashing, the server a key maps to is tied directly to the total number of servers. Change that number and you change the destination for almost every key.

Say you have keys A, B, C, D spread across 3 servers using hash(key) % 3. Add a fourth server and hash(key) % 4 reassigns roughly 75% of all keys to different servers. Remove a server and the same thing happens in reverse. Every scaling event triggers a near-total redistribution.

For a cache, this is catastrophic. All that warm cache data becomes unreachable because the keys are now pointing somewhere else. For a database shard, it means expensive data migrations just to resize your cluster.

The Hash Ring

Consistent hashing solves this by putting both servers and keys on the same circular space, called a hash ring.

Picture a circle numbered 0 to 2^32. You hash each server’s identifier (its IP address or name) and place it at that position on the ring. Then for each key, you hash it too and place it on the same ring. To find which server owns a key, you move clockwise from the key’s position until you hit a server. That is the server responsible for that key.

Four servers sit at positions 90, 180, 270, and 330 on the ring. A key hashing to position 45 moves clockwise and hits S1 at position 90 first. That is its owner. A key at position 200 hits S3 at 270. Every key finds its server by the same rule: move clockwise until you hit something.

What Happens When a Server Is Added or Removed

This is where consistent hashing earns its name.

Add a new server S4 at position 130. Only the keys sitting between S3 and S4 on the ring need to move. They were previously owned by S1 (the next clockwise server from that range), and now they belong to S4. Everything else stays exactly where it was.

Remove S1. The keys S1 owned move to S2, the next server clockwise. Nothing else moves.

In a cluster of N servers, adding or removing one server only affects roughly 1/N of all keys. With three servers you are moving about 33% of keys. With ten servers, about 10%. With a hundred, about 1%. The larger your cluster, the smaller the disruption.

Compare that to modulo hashing where adding one server to a hundred can still move the majority of keys.

The Virtual Nodes Problem

Basic consistent hashing has an issue. If you only place each server once on the ring, the distribution is uneven. One server might own 40% of the ring, another 5%. Hot spots form. One server gets hammered while others sit idle.

The fix is virtual nodes. Instead of placing each server once, you place it many times using different hash inputs.

hash("server-1-replica-1") -> position 45
hash("server-1-replica-2") -> position 178
hash("server-1-replica-3") -> position 312

Now Server 1 occupies three positions on the ring instead of one. With enough virtual nodes per server (typically 100 to 200 in production systems), the load distribution evens out significantly. It also means when you add a new server, it takes a proportional slice from every existing server rather than just one neighbor.

Where You Actually Run Into This

You have probably already used systems that rely on it without realising it.

Redis Cluster uses consistent hashing with hash slots. The ring is divided into 16,384 slots and each node owns a range of them. Adding a node means redistributing some slots, not all of them. Learn more about how Redis works as a cache.

Apache Cassandra uses it for distributing data across nodes. When you add a node to a Cassandra cluster, only a fraction of data moves, which is why Cassandra can scale horizontally with minimal disruption.

CDN providers use consistent hashing to decide which edge server caches a given piece of content. When an edge node goes down, only the content it was responsible for needs to be fetched from origin. Everything cached elsewhere stays put.

Memcached client libraries typically implement consistent hashing on the client side to route cache keys to the right node. Distributed message brokers like Apache Kafka use similar hashing techniques to distribute keyed messages across partitions.

The Tradeoffs Worth Knowing

Consistent hashing is not a perfect solution.

Even with virtual nodes, distribution is probabilistic. You get better balance with more virtual nodes, but more virtual nodes means more memory overhead tracking positions on the ring.

When a node fails, its load shifts entirely to the next clockwise node. Without careful capacity planning, you can create a cascade where the overloaded neighbor also fails, pushing its load to the next one, and so on. Some systems handle this by replicating data to the next N nodes clockwise so failure does not hit a single point.

Key hotspots can still happen if your hash function produces uneven distributions for your specific workload. Celebrity traffic in a social network (everyone requesting the same user profile) will hammer whatever node owns that key regardless of how well the ring is balanced overall.

The One Thing to Take Away

Consistent hashing decouples your data routing from the size of your cluster. With modulo hashing, your cluster size is baked into every routing decision. With consistent hashing, adding or removing a node is a local change on the ring, not a global redistribution. That property is what makes it fundamental to any distributed system that needs to scale without rebuilding itself every time.