Add one server? Everything reshuffles.
Remove one server? Cache gets wiped.
Traffic spikes? System collapses.
This is exactly the problem consistent hashing solves.
The Problem with Traditional Hashing
In a basic setup, you assign requests like this:
server = hash(key) % N
Where:
- key = user ID / request ID
- N = number of servers
Sounds fine… until N changes.
What breaks?
If you go from 3 → 4 servers:
- Almost all keys get remapped
- Cache becomes useless
- Database gets slammed
- Latency spikes
This is called the rehashing problem.
Enter Consistent Hashing
Consistent hashing avoids this chaos.
Instead of mapping keys directly to servers, it maps both servers and keys onto a ring.
How it works
- Imagine a circle (0 → 360 degrees or hash space)
- Hash each server → place it on the ring
- Hash each key → place it on the same ring
- A key is assigned to the next server clockwise
That’s it.
Why This Works
When a server is added or removed:
- Only a small portion of keys move
- Most of the system remains untouched
No massive reshuffling. No meltdown.
Real-World Example
Let’s say:
- You have 3 cache servers
- You store user sessions
Without consistent hashing:
- Adding a server invalidates almost all sessions
With consistent hashing:
- Only a fraction of users get reassigned
- System stays stable
But There’s a Catch
Servers might not be evenly distributed on the ring.
This creates:
- Uneven load
- Hotspots
Solution: Virtual Nodes
Instead of placing each server once:
- Place it multiple times on the ring
Example:
Server A → 100 positions
Server B → 100 positions
Now distribution becomes much more balanced.
Where It’s Used
Consistent hashing powers systems like:
- Distributed caches (Redis clusters)
- CDNs
- Databases like Cassandra
- Load balancers
If you’ve used Netflix, Amazon, or any large-scale system — this is already working behind the scenes.
When Should You Use It?
Use consistent hashing when:
- You have distributed systems
- Servers scale dynamically
- Cache stability matters
- You want minimal disruption during changes
Common Mistake
Most engineers:
- Learn hashing
- Ignore what happens when servers change
That’s where real systems break.
Consistent hashing is not optional at scale — it’s foundational.
Reacp:
Scaling isn’t just about adding servers.
It’s about how gracefully your system adapts when things change.
Consistent hashing is one of those simple ideas that quietly prevents disasters.
If you're building anything distributed — you need this.
Top comments (0)