How consistent hashing works
Why placing both data and servers on a circle lets a cluster grow or lose machines while moving only a small share of its data.
Written by Amili, an AI writer, from the sources listed below · 24 October 2026 · 5 min read
Consistent hashing is a way of spreading data across many servers so that adding or removing one server moves only a small fraction of the data. It places items and servers on the same circle, which keeps caches and distributed databases stable while machines join, crash or leave.
In short
- Ordinary hashing with a modulo step reshuffles almost every key when the server count changes.
- Consistent hashing maps keys and servers onto one circle; each key goes to the next server clockwise.
- Adding or removing a server only affects the keys next to it on the circle.
- Virtual nodes give each server several spots on the circle to even out the load.
- It underpins content delivery networks, distributed hash tables and many databases.
What problem does consistent hashing solve?
A hash function turns an item, such as a file name or a web address, into a number. The simplest way to share items across a cluster is to take that number, divide by the count of servers, and use the remainder to pick a server. It is fast and spreads items evenly.
The trouble starts when the server count changes. Because every assignment depends on that count, adding one machine or losing one to a crash changes the remainder for nearly every item. Almost all the data has to move, which is slow and expensive. Consistent hashing was designed so that a change in the cluster only disturbs the items that genuinely need a new home.
How does the hash ring work, step by step?
Picture a circle. Each server is hashed, using something like its IP address or a unique ID, to a point on that circle. Each item is hashed onto the same circle. To find where an item lives, start at its point and move clockwise until reaching the first server; that server owns it. If no server lies further round, the search wraps to the server with the smallest position.
Programs usually keep the server positions in a sorted structure, such as a binary search tree, so the next server clockwise can be found with a binary search rather than a scan of every machine.
When a server fails, only the items it held move, and they go to the next server clockwise. When a new server joins, it takes over only the items that now fall just before it, which previously belonged to its clockwise neighbour. Every other item stays put. On average, a change shifts roughly one server's share of the keys rather than all of them.
What does a worked example look like?
Imagine four cache servers, W, X, Y and Z, spaced around the circle, and a few thousand cached web pages scattered between them. Each server holds the pages that sit just counter-clockwise of it, roughly a quarter each.
Now server Y crashes. With modulo hashing, dividing by three instead of four would send most pages to a different server. On the ring, only Y's pages are affected: they slide to Z, the next server clockwise, and the pages on W, X and Z stay exactly where they were.
For web caches, often nothing even has to be copied. The first request for a moved page simply misses at its new server, which fetches it from the original site and keeps a copy. The stale copies elsewhere fade out under normal eviction rules.
How are the rough edges smoothed out?
With only a handful of servers, random positions can leave some servers owning large arcs of the circle and others tiny ones. The usual fix is virtual nodes: each physical server is placed on the circle many times under different labels. The number of labels a server gets is called its weight, so a more powerful machine can be given a larger share.
Virtual nodes also help when a server fails. In the basic scheme its whole load lands on a single neighbour, possibly doubling that neighbour's work. With many scattered positions, the failed server's items are spread over several different successors instead. Popular, frequently requested items can be copied to several consecutive servers going clockwise, so no single machine carries all the traffic for them.
Where is it used, and where does it fall short?
The term was introduced by David Karger and colleagues at MIT in a 1997 paper about distributed web caching. Akamai, co-founded in 1998 by two of the paper's authors, Daniel Lewin and F. Thomson Leighton, uses it to balance load within server clusters in its content delivery network. Tim Berners-Lee has credited the technique with solving the slashdotting problem that troubled the web in the 1990s. It also forms the basis of distributed hash tables and appears in systems including Amazon's Dynamo, Apache Cassandra, Riak, Couchbase, OpenStack Swift and Discord.
It is not always the best tool. Rendezvous hashing, designed in 1996, is simpler and more general, and consistent hashing can be shown to be a special case of it; many applications now prefer it. Two popular items that hash close together can end up sharing the same set of servers. And when keys only ever increase, a table built around monotonic keys may suit the job better.
What does consistent hashing teach about designing systems?
The lesson is to design for change rather than for a fixed snapshot. Modulo hashing is perfect for a cluster that never changes, and fragile for one that does. Consistent hashing accepts a little extra bookkeeping in exchange for a system where failure and growth are local events instead of global ones.
It also illustrates how redundancy and spreading the load go together. Giving each server several positions and copying hot items to neighbours keeps any one failure from becoming everyone's problem.
Questions people ask
Why not just use hash modulo the number of servers?
Because the result depends directly on the server count. When a machine is added or lost, that count changes and almost every key maps to a different server, forcing a near-total reshuffle of the data. Consistent hashing ties each key to a position on a circle instead, so a change in membership only moves the keys that sat next to the server that joined or left.
What are virtual nodes in consistent hashing?
Virtual nodes are extra labels that place one physical server at several points on the hash ring. They reduce the uneven spread that comes from having few servers at random positions, and they let operators give stronger machines more positions, called a higher weight. When a server fails, its many small arcs are picked up by different neighbours, so the extra load is shared instead of landing on one machine.
How is consistent hashing related to distributed hash tables?
A distributed hash table stores key-value pairs across many cooperating nodes, and most designs use consistent hashing or rendezvous hashing to decide which node owns each key. The shared property is that a node arriving or leaving only changes ownership for keys near it, leaving the rest untouched. That keeps data movement low and lets such systems cope with machines constantly joining, leaving and failing.
The thinking behind it
Its chapters on hashing and binary search trees explain the two building blocks that a consistent hash ring combines.
Read or listen to Introduction to Algorithms
Hear the whole book free: start an Audible trial and your first audiobook — this one, if you like — is on the house.
As an Amazon Associate, ReadGlobe earns from qualifying purchases and Audible trials — at no extra cost to you.
Sources
- Consistent hashing — Wikipedia
- Distributed hash table — Wikipedia
How this was made: Amili, an AI writer, wrote this article in its own words from the sources above. Every link was checked before publishing. Spotted an error? Tell us and we will correct it.