Consistent Hashing, Explained Visually

Most distributed systems eventually face the same routing question: given a key, which server should own it? The answer needs to stay predictable as the cluster grows and shrinks.

Consistent hashing is a placement strategy designed for exactly that problem. It is used in caches, databases, content delivery networks, and other systems that spread data across many machines.

The problem with ordinary hashing

A straightforward sharding rule looks like this:

const serverIndex = hash(key) % servers.length;

With three servers, every key maps to index 0, 1, or 2. This works while the server count stays fixed. If a fourth server is added, the divisor changes from 3 to 4, so most keys produce a different remainder.

That creates a large remapping event. Cache entries become misses, database partitions need to move, and many requests suddenly reach servers that do not own their data.

Turn the hash space into a ring

Consistent hashing treats the hash range as circular. After the largest possible hash value, the range wraps back to zero.

Both servers and data keys are hashed onto this ring:

1. Hash each server identifier to choose its position.
2. Hash a key to choose its position.
3. Walk clockwise from the key.
4. Assign the key to the first server encountered.

The important idea is that a key depends on its position and its immediate clockwise server—not on the total number of servers.

What happens when a server joins?

Suppose server D is inserted between servers C and A. Only the keys in that section of the ring move to D. Keys owned by B and C remain where they are.

Removing a server has the same local effect in reverse: its keys move to the next server clockwise. The rest of the ring remains stable.

For n servers, adding or removing one server moves roughly 1 / n of the keys when distribution is reasonably balanced. Ordinary modulo hashing may remap nearly all of them.

Virtual nodes fix uneven distribution

One physical server at one ring position can lead to uneven ranges. A server might own a large arc while another owns a very small one.

Production implementations usually create many virtual nodes for each physical server. Instead of hashing server-a once, the system hashes identifiers such as server-a#1, server-a#2, and server-a#3.

Virtual nodes spread each physical server around the ring. This gives a more even key distribution and makes it possible to give a powerful machine more virtual nodes than a smaller one.

A small TypeScript implementation

The core lookup can stay compact. A production version would use a stronger hash and enough virtual nodes for the expected load.

type RingEntry = {
  hash: number;
  server: string;
};

function findServer(ring: RingEntry[], keyHash: number) {
  const entry = ring.find((point) => point.hash >= keyHash);

  // Wrap around to the first point when the key is past the final node.
  return (entry ?? ring[0]).server;
}

The ring entries are sorted by hash. A real implementation should use binary search, making lookup O(log n) instead of scanning the array.

Where it works well

Consistent hashing is useful when nodes change and moving data is expensive:

• distributed caches
• partitioned key-value stores
• request routing
• CDN edge selection
• storage systems

It is less useful when the cluster rarely changes, when perfectly even balancing matters more than movement, or when each item has very different cost. Some systems use alternatives such as rendezvous hashing for simpler membership changes and comparable stability.

The mental model

Remember one sentence: place servers and keys on the same ring, then walk clockwise.

That small change removes the server count from the placement formula. As membership changes, only a neighboring slice of the keyspace needs to move—and that is why consistent hashing scales gracefully.