Consistent Hashing

Consistent hashing distributes data across nodes so that adding or removing a node only moves a small fraction of keys, not all of them. Traditional hash-mod-N remaps almost every key when N changes. Consistent hashing maps both keys and nodes to a virtual ring, and each key goes to the nearest node clockwise — making it essential for distributed caches, databases, and load balancers.

The Core Idea

Consistent hashing is a distributed hashing technique that minimizes key redistribution when nodes are added or removed from a system. In traditional hashing (key % N), adding one server reshuffles almost all keys. With consistent hashing, only K/N keys are remapped (where K is total keys and N is total nodes).

Step-by-Step Walkthrough

Imagine a clock face numbered 0 to 360. Hash each server's name to get its position: Server A → 90°, Server B → 210°, Server C → 330°. Hash each key to get its position: key1 → 120°. Walk clockwise from 120° — the first server you hit is Server B (210°), so key1 is stored on Server B.

When Server B is removed, only the keys between Server A (90°) and Server B (210°) need to move — they shift to Server C. Keys on Server A and Server C are unaffected. This is the magic of consistent hashing: minimal disruption.

Virtual nodes solve hot spots. Instead of 3 points on the ring, you place 300 (100 per server). This distributes load evenly even when physical servers have different capacities.

Why This Approach Wins

• Hash ring: Both keys and servers are mapped onto a circular hash space (0 to 2^32). A key is assigned to the first server encountered clockwise on the ring.
• Minimal disruption: When a server is added or removed, only the keys between it and its predecessor need to be reassigned — approximately K/N keys.
• Virtual nodes: To solve uneven distribution, each physical server is mapped to multiple positions on the ring (100-200 virtual nodes). This ensures balanced load even with few physical servers.
• Replication: In databases like Cassandra, data is replicated to the next N nodes clockwise on the ring for fault tolerance.

In Production

Amazon DynamoDB uses consistent hashing to partition data across storage nodes. Adding capacity just redistributes a fraction of the data.

Akamai CDN pioneered consistent hashing to route requests to the nearest cache server holding the requested content.

Discord uses consistent hashing to assign guilds (servers) to backend processes for message handling.

Tradeoffs and Limitations

• Load balance vs. Complexity: Virtual nodes improve balance but add memory overhead for the routing table.
• Consistency vs. Availability: During rebalancing, some keys may be temporarily unavailable or stale.
• Simplicity vs. Flexibility: Simple mod hashing is easier to implement but breaks badly during scaling.

Production Gotchas

1. Not using virtual nodes — bare consistent hashing can lead to very uneven distribution
2. Using a poor hash function — MD5 or SHA are fine; simple modular hashing is not
3. Forgetting about replication — consistent hashing alone does not provide fault tolerance

The Interview Angle

1. Explain how consistent hashing works and why it is better than modular hashing.
2. What problem do virtual nodes solve?
3. How is consistent hashing used in distributed caching?
4. How would you handle replication with consistent hashing?
5. What happens when a node fails in a consistent hashing ring?

Next Up

• Database Sharding
• Load Balancing
• Distributed Caching
• distributed-kv-store
• consistent-hashing-code

How to Explain This in an Interview

Here is how I would explain Consistent Hashing in a system design interview:

Consistent hashing solves a specific problem: how do you distribute data across N nodes so that changing N does not remap everything? Imagine a ring from 0 to 2^32. Hash each node and each key onto this ring. Each key maps to the first node found clockwise from its hash position. When you add a node, only the keys between the new node and its predecessor move — everything else stays put. The practical improvement interviewers expect you to mention is virtual nodes: each physical node gets 100-200 positions on the ring, which smooths out the distribution. Without virtual nodes, one physical node going down dumps all its keys onto a single neighbor, potentially overloading it.

Consistent Hashing in .NET

Here is a production-ready consistent hashing implementation in C#:

public class ConsistentHash<T>
    private readonly SortedDictionary<uint, T> _ring = new();
    private readonly int _virtualNodes;

    public ConsistentHash(IEnumerable<T> nodes, int virtualNodes = 150)
        _virtualNodes = virtualNodes;
        foreach (var node in nodes) AddNode(node);

    public void AddNode(T node)
        for (int i = 0; i < _virtualNodes; i++)
            uint hash = ComputeHash($"{node}-vn{i}");
            _ring[hash] = node;

    public T GetNode(string key)
        uint hash = ComputeHash(key);
        // Find first node clockwise from the key's hash
        foreach (var kvp in _ring)
            if (kvp.Key >= hash) return kvp.Value;
        return _ring.First().Value; // Wrap around

    private static uint ComputeHash(string key)
        using var md5 = System.Security.Cryptography.MD5.Create();
        var bytes = md5.ComputeHash(Encoding.UTF8.GetBytes(key));
        return BitConverter.ToUInt32(bytes, 0);

Where .NET developers use this: The Microsoft Orleans framework (virtual actor model) uses consistent hashing internally to distribute grains (actors) across silos (servers). When you build a game backend or IoT system with Orleans, consistent hashing ensures that each actor instance lives on a specific server without explicit routing.

StackExchange.Redis also uses consistent hashing when connecting to Redis Cluster — the client library hashes keys to determine which Redis node to query, transparently routing your requests.

Original DosiBridge notes for Consistent Hashing

This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Consistent Hashing is to connect the concept to a production service where growth exposes the first weak assumption in the original design. That framing changes the design discussion from definitions to operating choices.

What makes this topic distinct

• SLO: For Consistent Hashing, decide the SLO before choosing tools; otherwise the design looks clean but fails when consistent changes.
• Capacity Headroom: For Consistent Hashing, decide the capacity headroom before choosing tools; otherwise the design looks clean but fails when hashing changes.
• Failure Mode: For Consistent Hashing, decide the failure mode before choosing tools; otherwise the design looks clean but fails when consistent changes.
• Degradation Path: For Consistent Hashing, decide the degradation path before choosing tools; otherwise the design looks clean but fails when hashing changes.
• Operator Signal: For Consistent Hashing, decide the operator signal before choosing tools; otherwise the design looks clean but fails when consistent changes.

Production review question

If a team adopts Consistent Hashing, what observable signal proves it helped instead of only making the architecture diagram more fashionable?

Practical metric to track

Track consistent-hashing health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Consistent Hashing, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.