Consistent Hashing in Practice

The problem

Imagine a cache cluster with 10 servers.

You send each key to a server using:

hash(key) % 10

That works fine until one more server joins.

Now the formula becomes:

hash(key) % 11

Result: a huge number of keys move somewhere else. The cache is almost invalidated at once. The database takes the hit.

That is the problem consistent hashing is trying to solve.

Mental model

Consistent hashing tries to do two things at the same time:

• distribute keys
• move as few of them as possible when the cluster changes

Instead of thinking in terms of “server 1, 2, 3,” think about a ring.

Both servers and keys are placed on that ring through a hash function. Each key goes to the first server found clockwise.

When a server joins or leaves, only the keys from that neighborhood need to move. The rest stay where they were.

That is the core idea.

It does not mean “no key moves.” It means “a much smaller slice moves.” That is exactly what makes the technique useful.

Breaking the problem down

Why plain hashing hurts

Plain hashing with % N depends directly on the number of nodes.

If N changes, the formula changes for almost everyone. That is why almost all keys jump to different servers.

That is bad for distributed load because it:

• invalidates cache in bulk
• creates an origin spike
• makes rebalancing expensive

How the consistent-hashing ring works

On the ring, you do not think “this key belongs to server 3.”

You think “this key lands at a point on the ring and walks clockwise until it finds a server.”

If a new server appears between two points, only the keys from that slice start pointing to it.

That property is the heart of the topic.

Virtual nodes: why they exist

If you only have a few physical servers, the ring can become uneven. One node may end up owning too large a range.

A virtual node means placing several points from the same server on the ring.

In plain language:

• one physical server appears several times on the ring
• that helps spread load more evenly
• when a server leaves, redistribution becomes smoother

Where it shows up in real life

You see this a lot in:

• distributed cache
• key-based partitioning
• ownership routing
• some databases and storage systems

This is not trivia for its own sake. It is a practical mechanism for growing a cluster without throwing everything into the air.

It is also worth remembering what it does not solve by itself:

• hot keys
• slow nodes
• bad business keys that create skew

Consistent hashing improves redistribution. It does not erase every distribution problem.

How it appears in interviews

This topic usually shows up when the interviewer notices that you proposed several nodes and wants to know how the keys actually land on each one.

If you only say “I split by hash” and stop there, you may miss the important follow-up: what happens when the cluster changes?

Simple example

Imagine a distributed cache for user profiles.

With % N, adding one server during a big promotion may move almost everything. The cache warms from zero. The origin suffers.

With consistent hashing, that new server only pulls part of the keys. The rest of the cluster keeps serving traffic normally. Warming still happens, but on a smaller slice and with much less trauma.

It is not magic. Redistribution still exists. It just stops being an avalanche.

Common mistakes

• Explaining only the ring without first showing the % N problem.
• Ignoring the role of virtual nodes.
• Talking about consistent hashing as if it solved everything by itself.
• Using the term to sound deep without tying it to a concrete case.
• Forgetting that hot keys are still a problem even with a better distribution method.

How a senior thinks about it

People with more experience usually start from the reason it exists:

“I do not want changing the cluster size to invalidate almost every key.”

Only after that do they talk about the ring, virtual nodes, and the mechanics.

That makes the explanation much better because the reader understands the pain first and the technique second.

In real work, this also helps avoid decorative use. If the cluster almost never changes or redistribution is not expensive, the gain may not justify the complexity. This topic matters when moving too many keys at once actually hurts.

What the interviewer wants to see

In interviews, consistent hashing gets stronger when you:

• explain why % N fails
• show why the ring reduces reshuffling
• mention virtual nodes without turning them into ritual
• connect the topic to real cache or sharding

Consistent hashing is not about drawing a pretty circle. It is about growing a cluster without shaking almost every key at once.