How Consistent Hashing Powers Distributed Systems

Consistent hashing is one of those ideas that sounds complicated until you see the picture — then it’s obvious, beautiful, and you wonder how anything worked before it.

The problem: hash % N doesn’t scale

Imagine you have 4 cache servers and you want to distribute keys across them. The naive approach is hash(key) % N — pick a server by taking the key’s hash modulo the server count.

It works perfectly until N changes. Add a fifth server and almost every key now maps to a different bucket. That triggers a cache miss avalanche — every client races to the database to repopulate a cache that was warm a moment ago.

Bump N from 4 to 5 and the modular arithmetic shifts for almost every key — the buckets themselves haven’t moved, but the remainder changes for most hashes. The cache that was warm a second ago is suddenly cold across the board.

The ring

Consistent hashing places both servers and keys on a conceptual ring of 2³² positions, [0, 2³²). Every server is hashed to a position on that ring. Every key is hashed to a position on the same ring and is owned by the first server you encounter going clockwise from the key’s hash position.

When you add a server, it lands somewhere on the ring and takes ownership of the keys between it and its counter-clockwise neighbor. When you remove a server, its keys pass to its clockwise successor. In both cases, only 1/N of keys are affected — the rest stay where they are.

Adding a server moves one boundary, not the whole keyspace — and that’s exactly where the members-only walkthrough picks up: a live ring you can drag nodes around, virtual node mechanics, the vnodes-vs-real-nodes tradeoff, and how Cassandra and Amazon Dynamo put this into production.