Home / System Design / Consistent Hashing

🔗 Consistent Hashing

Fundamentals ⏱ 6 min read

Consistent hashing solves a specific but crucial problem: how to distribute data across a changing set of servers without reshuffling almost everything each time a server is added or removed.

The problem with naive hashing

A simple scheme like server = hash(key) % N works — until N changes. Add or remove one server and the modulus changes for almost every key, so nearly all data has to move. For a distributed cache that means a mass cache-miss storm; for a database, a huge migration.

The hash ring

Consistent hashing maps both servers and keys onto a circle (the hash ring, 0 to 2³²−1). A key is stored on the first server found by moving clockwise from the key's position. Now, adding or removing a server only affects the keys between it and its neighbour — roughly 1/N of the data moves, not all of it.

Virtual nodes

With few servers, the ring can be uneven — one server may own a big arc and get overloaded. The fix is virtual nodes: each physical server is placed at many points on the ring. This smooths the distribution and lets you weight more powerful servers with more virtual nodes.

Where it is used

Consistent hashing powers distributed caches (like Memcached client rings), databases such as Cassandra and DynamoDB, and load balancers that need cache locality. It pairs naturally with sharding.

Frequently Asked Questions

Why not just use hash(key) % N?
Because when N (the number of servers) changes, the result changes for almost every key, forcing nearly all data to move. Consistent hashing moves only about 1/N of the keys when a server is added or removed.
What are virtual nodes in consistent hashing?
Virtual nodes place each physical server at many points on the hash ring, which evens out the data distribution and lets stronger servers hold proportionally more data.