Consistent Hashing

What is it?

A simple way to decide which server holds a piece of data is hash(key) % numberOfServers — but there's a serious problem: the moment the number of servers changes (one is added, or one fails), that formula's result changes for nearly every key, meaning almost all data would need to move at once. Consistent hashing is a technique that avoids this: it arranges both servers and data on a conceptual circle (a hash ring), so that adding or removing a server only affects the small slice of data near it on the ring — not everything.

Explain like I'm 10

Imagine seats arranged in a circle, and guests are assigned to the nearest empty seat clockwise from wherever their name happens to land on that circle. If one seat is removed, only the guest who was sitting there needs to move to the next seat over — everyone else stays exactly where they were. Compare that to a rule like 'seat number = name length % total seats,' where adding or removing even one seat reshuffles almost everyone.

Examples

The core idea of a hash ring

// Simplified: servers and keys both hashed onto the same circular range
const servers = [{ id: "server-A", position: 10 }, { id: "server-B", position: 200 }];

function getServerForKey(key) {
  const keyPosition = hash(key) % 360; // hash onto the same circle
  // find the first server at or after keyPosition, wrapping around
  return servers
    .sort((a, b) => a.position - b.position)
    .find((s) => s.position >= keyPosition) ?? servers[0];
}

How it works

Both servers and data keys are hashed onto the same circular range of values. Each key belongs to whichever server is the next one clockwise from the key's position on the ring. When a server is added, it only takes over the keys between itself and the previous server on the ring — everything else stays exactly where it was. When a server is removed, only its keys need to move, to the next server clockwise.

Why does it exist?

Without consistent hashing, adding or removing even one server from a sharded or distributed cache system would force nearly all data to be relocated at once — an expensive, disruptive operation. Consistent hashing makes scaling a distributed system up or down dramatically cheaper by minimizing how much data actually needs to move.

When to use it

Reach for consistent hashing when building or choosing a distributed cache or sharded data store that needs to grow or shrink its number of servers over time without an expensive full data reshuffle — this is exactly how systems like distributed caches and some NoSQL databases decide where data lives.

When not to use it

For a fixed, small number of servers that will essentially never change, the simpler hash(key) % numberOfServers approach is easier to reason about and implement — consistent hashing earns its complexity specifically when server count changes over time.

Common mistakes

• Using simple modulo hashing (hash(key) % n) for a system expected to scale up or down, then being surprised by a massive, disruptive data reshuffle when the server count changes.

• Forgetting that a naive hash ring can distribute data unevenly if servers happen to land close together on the ring — real implementations add multiple 'virtual nodes' per server to smooth this out.

• Assuming consistent hashing eliminates all data movement on a server change — it minimizes it, but the affected slice still has to move somewhere.

Practice exercises

1. Easy:

   Explain, in your own words, why hash(key) % numberOfServers causes almost all data to move when a server is added.

2. Medium:

   Describe how consistent hashing limits the amount of data that moves when a new server joins.

3. Hard:

   Explain what 'virtual nodes' are in consistent hashing and why they help distribute data more evenly.

Interview questions

What problem does consistent hashing solve?

It minimizes how much data needs to move when the number of servers in a distributed system changes, compared to simple modulo-based hashing which reshuffles almost everything.

How does a hash ring decide which server owns a given key?

The key is hashed onto the same circular range as the servers, and it belongs to whichever server is next going clockwise from the key's position.

What are virtual nodes, and why are they used?

Multiple positions on the ring assigned to each real server, so data is spread more evenly instead of depending on the luck of where each server happens to land.