When a distributed system grows, data often needs to be distributed across multiple servers.
For example, imagine an application with millions of users. Storing all user data on a single server may create performance, scalability, and availability problems. Instead, the system can distribute data across multiple servers.
But this creates an important question:
How does the system decide which server should store a particular piece of data?
A simple approach is to use a hash function and assign data to servers using modulo.
For example:
serverIndex = hash(key) % numberOfServers
This works when the number of servers remains unchanged.
However, distributed systems frequently add or remove servers. When that happens, the number of servers changes, and the modulo calculation can send a large amount of existing data to different servers.
This can cause major problems.
Consistent hashing solves this problem by minimizing the amount of data that needs to be redistributed when servers are added or removed.
In this guide, you’ll learn what consistent hashing is, how it works, why traditional hashing creates problems, the hash ring, virtual nodes, and real-world use cases.
What Is Consistent Hashing?
Consistent hashing is a hashing technique used in distributed systems to distribute data across multiple servers while minimizing data redistribution when servers are added or removed.
Instead of directly mapping data using:
hash(key) % numberOfServers
consistent hashing places both:
- Servers
- Data keys
on the same logical structure called a hash ring.
Each key is assigned to a server based on its position on the ring.
The main benefit is that when a server is added or removed, only a portion of the data needs to move.
Why Is Consistent Hashing Needed?
Let’s first understand the problem with traditional hashing.
Suppose we have three servers.
Server 0
Server 1
Server 2
We distribute users using:
hash(userId) % 3
For example:
hash(UserA) % 3 → Server 0
hash(UserB) % 3 → Server 2
hash(UserC) % 3 → Server 1
Everything works correctly.
Now imagine we add another server.
Server 0
Server 1
Server 2
Server 3
The formula becomes:
hash(userId) % 4
Now many keys may produce completely different results.
Before:
hash(UserA) % 3 → Server 0
After:
hash(UserA) % 4 → Server 2
As a result, a large amount of data may need to be redistributed.
This is inefficient, especially when dealing with:
- Large databases
- Distributed caches
- High-traffic applications
- Large numbers of servers
Consistent hashing reduces this redistribution problem.
How Does Consistent Hashing Work?
Consistent hashing uses a conceptual circular space called a hash ring.
A hash function converts servers and keys into positions on this ring.
For example:
Hash Ring
Server A
●
/ \
/ \
Server C ● ● Server B
\ /
\ /
●
Keys
The hash function generates a value within a fixed range.
For example:
0 -------------------------- 2³² - 1
The beginning and end are connected, creating a circular structure.
Step 1: Place Servers on the Hash Ring
Each server is hashed and placed at a position on the ring.
hash(Server A)
hash(Server B)
hash(Server C)
Conceptually:
Server A
●
/ \
/ \
Server C ● ● Server B
\ /
\ /
○
The exact location depends on the hash function.
Step 2: Place Keys on the Hash Ring
Data keys are also hashed.
For example:
hash(User1)
hash(User2)
hash(Product123)
These keys are placed at positions on the same ring.
Server A
●
Key 1 ○
/ \
/ \
Server C ● ● Server B
\ /
\ /
Key 2 ○
Step 3: Assign Each Key to a Server
A common rule is:
Move clockwise around the ring until you find the first server.
That server becomes responsible for the key.
For example:
Key A
↓
Move Clockwise
↓
First Server
↓
Store Key There
Suppose the ring looks like this:
0
│
│ Server A
│ ●
│
│ Key 1 ○
│
│ Server B
│ ●
│
│ Key 2 ○
│
│ Server C
│ ●
│
└───────────────
The assignment might be:
Key 1 → Server B
Key 2 → Server C
Each key belongs to the next available server in the clockwise direction.
What Happens When a New Server Is Added?
This is where consistent hashing becomes useful.
Suppose we initially have:
Server A
Server B
Server C
Now we add:
Server D
Server D is placed somewhere on the hash ring.
Before:
Server A → Server B → Server C
After:
Server A → Server D → Server B → Server C
Only the keys that fall between the previous server and the new server need to move.
For example:
Before:
Keys → Server B
After Server D Is Added:
Some Keys → Server D
Remaining Keys → Server B
Most other keys remain on their existing servers.
This is the key advantage of consistent hashing.
What Happens When a Server Is Removed?
Suppose the ring contains:
Server A
Server B
Server C
If Server B fails:
Server A
Server C
The keys previously assigned to Server B can be moved to the next available server on the ring.
Keys Assigned to Server B
↓
Next Server Clockwise
↓
Server C
Other servers do not need to redistribute all their data.
Traditional Hashing vs Consistent Hashing
| Feature | Traditional Hashing | Consistent Hashing |
|---|---|---|
| Server Selection | hash(key) % N | Hash ring |
| Adding Servers | Large redistribution | Limited redistribution |
| Removing Servers | Large redistribution | Limited redistribution |
| Scalability | Less flexible | More flexible |
| Common Use | Fixed server count | Distributed systems |
The biggest difference is what happens when the number of servers changes.
What Is a Hash Ring?
A hash ring is a conceptual circular representation of the possible output values of a hash function.
For example:
0 ---------------- 100
In a normal line, the beginning and end are separate.
In a consistent hashing ring:
0
↑ ↓
← ← ← ← ←
The range wraps around.
For example:
0
/ \
/ \
75 / \ 25
| |
50 \ /
\ /
100
After reaching the maximum hash value, the system continues from the beginning.
This allows every key to find a server even if its position is after the last server on the ring.
What Are Virtual Nodes?
One challenge with basic consistent hashing is uneven data distribution.
Imagine only three physical servers placed on a large ring.
Server A
●
Server B
●
Server C
●
The spaces between them may not be equal.
As a result:
Server A → 10% of keys
Server B → 60% of keys
Server C → 30% of keys
This creates an imbalance.
Virtual nodes solve this problem.
Instead of placing each physical server on the ring once, each server is represented multiple times.
For example:
Server A → A1, A2, A3
Server B → B1, B2, B3
Server C → C1, C2, C3
The ring now looks more evenly distributed.
A1 → B1 → C1 → A2 → B2 → C2 → A3 → B3 → C3
Each physical server owns multiple positions.
This generally improves data distribution.
Why Are Virtual Nodes Important?
Virtual nodes provide several advantages.
Better Load Distribution
Data is distributed more evenly.
Easier Scaling
When a new server is added, it can receive multiple positions across the ring.
Better Failure Handling
If a server fails, its virtual nodes can be redistributed among multiple servers.
Support for Different Server Capacities
More powerful servers can potentially be assigned more virtual nodes.
For example:
Small Server → 5 Virtual Nodes
Large Server → 20 Virtual Nodes
This allows the distribution to reflect server capacity.
Consistent Hashing Example
Imagine four cache servers.
Cache Server A
Cache Server B
Cache Server C
Cache Server D
A user profile key is:
user:123
The application hashes the key:
hash("user:123")
The resulting position is placed on the hash ring.
The system then moves clockwise until it finds a server.
user:123
↓
Hash Position
↓
Move Clockwise
↓
First Server
↓
Cache Server B
The data is stored on Cache Server B.
Adding a New Cache Server
Now suppose a new cache server is added.
Cache Server E
Server E is added to the ring.
Before:
A → B → C → D
After:
A → B → E → C → D
Only keys located in the portion of the ring assigned to Server E need to move.
The other servers continue handling most of their existing keys.
This makes consistent hashing useful for distributed caches.
Consistent Hashing in Distributed Caching
One of the most common use cases is distributed caching.
Suppose you have several cache servers.
Application
↓
Cache Cluster
Cache 1
Cache 2
Cache 3
The application needs to determine which cache server contains a key.
Consistent hashing can be used.
hash(cacheKey)
↓
Hash Ring
↓
Select Server
For example:
user:100 → Cache Server A
user:200 → Cache Server C
user:300 → Cache Server B
If another cache server is added, only a portion of the keys need to move.
Consistent Hashing in Databases
Consistent hashing can also be used in distributed databases.
Data can be distributed based on:
- User ID
- Account ID
- Product ID
- Other partition keys
Example:
hash(userId)
↓
Hash Ring
↓
Database Node
This helps distribute data across multiple nodes.
However, real database partitioning systems may include additional mechanisms for:
- Replication
- Rebalancing
- Consistency
- Failover
- Query routing
Consistent hashing is one approach to data distribution, not a complete distributed database solution by itself.
Consistent Hashing and Load Balancing
Consistent hashing can also be useful for request routing.
For example, some systems may want requests from the same user to consistently reach the same backend node.
hash(userId)
↓
Select Server
This can be useful for workloads involving:
- Cached user data
- Session affinity
- Stateful services
However, consistent hashing is different from traditional load balancing algorithms such as Round Robin or Least Connections.
A load balancer focuses on distributing requests.
Consistent hashing focuses on consistently mapping keys to nodes.
Consistent Hashing vs Round Robin
| Consistent Hashing | Round Robin |
|---|---|
| Maps keys to nodes | Distributes requests sequentially |
| Uses a hash function | Cycles through servers |
| Useful for data locality | Useful for even request distribution |
| Minimizes remapping | Does not preserve key-to-server mapping |
The correct choice depends on the problem being solved.
Replication in Consistent Hashing
Distributed systems often need redundancy.
Suppose a key is assigned to Server A.
Key
↓
Server A
The system may also store copies on additional servers.
Key
↓
Server A
↓
Server B
↓
Server C
A replication strategy can improve:
- Availability
- Fault tolerance
- Data durability
In a hash ring, replicas may be placed on the next nodes around the ring.
The exact replication strategy depends on the system’s design.
Common Real-World Use Cases
Consistent hashing is commonly associated with systems involving distributed nodes and changing cluster sizes.
1. Distributed Caches
Examples:
- Cache clusters
- Session storage
- Distributed key-value stores
2. Distributed Databases
Consistent hashing can help distribute data across multiple nodes.
3. Content Distribution
Requests or content identifiers can be mapped consistently to nodes.
4. Stateful Services
A key such as a user ID can help route related requests to the same node.
5. Message Processing
Some distributed processing systems use hashing techniques to consistently partition workloads.
Advantages of Consistent Hashing
1. Reduced Data Movement
When nodes change, only part of the data needs to be reassigned.
2. Better Scalability
Servers can be added or removed more easily.
3. Improved Availability
Failed nodes affect only a portion of the key space.
4. Distributed Data Storage
Data can be distributed across multiple servers.
5. Better Load Distribution with Virtual Nodes
Virtual nodes help create a more balanced distribution.
Limitations of Consistent Hashing
Consistent hashing also has challenges.
Uneven Distribution Without Virtual Nodes
A small number of physical nodes may create uneven partitions.
Node Management Complexity
The system needs to track:
- Active nodes
- Failed nodes
- Added nodes
- Removed nodes
Rebalancing Still Exists
Consistent hashing reduces data movement.
It does not eliminate it.
When nodes are added or removed, some keys still need to move.
Replication Adds Complexity
If the system uses replicas, it must manage:
- Replica placement
- Consistency
- Failover
- Recovery
Common Mistakes When Learning Consistent Hashing
1. Thinking No Data Moves
Consistent hashing does not mean zero redistribution.
It means significantly less redistribution compared with traditional modulo hashing when the cluster changes.
2. Forgetting Virtual Nodes
Basic consistent hashing can produce uneven distribution.
Virtual nodes are commonly used to improve balance.
3. Confusing Consistent Hashing with Encryption
Hashing in this context is used for deterministic data distribution.
It is not encryption.
4. Confusing It with Regular Load Balancing
Consistent hashing maps a key to a node.
Traditional load balancing algorithms distribute requests based on traffic or server conditions.
How to Think About Consistent Hashing in System Design Interviews
When a system design problem involves:
- Distributed caches
- Database sharding
- Multiple storage nodes
- Horizontal scaling
- Frequently changing cluster sizes
Ask:
How will data be mapped to nodes when servers are added or removed?
If changing the number of servers would cause large-scale remapping, consistent hashing may be a useful approach.
A simple explanation during an interview could be:
Consistent hashing distributes both servers and keys across a hash ring. Each key is assigned to the next server clockwise, so adding or removing a server only affects a portion of the keys instead of requiring widespread redistribution.
Frequently Asked Questions
What Is Consistent Hashing in Simple Words?
Consistent hashing is a method for distributing data across multiple servers so that when a server is added or removed, only a small portion of the data needs to move to different servers.
Why Is Consistent Hashing Better Than Modulo Hashing?
Modulo hashing depends directly on the number of servers. When the number changes, many keys can map to different servers.
Consistent hashing reduces this remapping by using a hash ring where only keys near the added or removed server are affected.
What Is a Hash Ring?
A hash ring is a conceptual circular range of hash values where both servers and data keys are placed. A key is typically assigned to the next server found when moving clockwise around the ring.
What Are Virtual Nodes?
Virtual nodes represent a physical server multiple times on the hash ring. They help distribute data more evenly and can support servers with different capacities.
Where Is Consistent Hashing Used?
Consistent hashing is commonly used in distributed caches, distributed databases, storage systems, request routing, and other distributed architectures.
Does Consistent Hashing Eliminate Rebalancing?
No.
Some data still needs to move when servers are added or removed. Consistent hashing reduces the amount of redistribution compared with traditional modulo-based hashing.
Conclusion
Consistent hashing is an important concept in distributed system design.
Traditional hashing works well when the number of servers remains fixed:
hash(key) % numberOfServers
However, when servers are added or removed, this approach can cause large amounts of data to be reassigned.
Consistent hashing solves this problem by placing both keys and servers on a hash ring.
Each key is assigned to the next available server on the ring.
When a server is added or removed:
- Only a portion of keys need to move.
- Most existing mappings remain unchanged.
- Scaling becomes easier.
Virtual nodes further improve the system by providing more balanced data distribution.
Consistent hashing is especially useful for understanding larger system design topics such as:
- Distributed caching
- Database sharding
- Horizontal scaling
- Data partitioning
- Fault tolerance
- Distributed storage
Once you understand consistent hashing, you can better understand how large distributed systems continue operating efficiently even as servers are added, removed, or replaced.
