distributed · distributed-systems · hashing

Consistent hashing without the magic

2026-07-192 min readdistributed

Consistent hashing shows up in every distributed systems interview — and in production at NotiQ, Cassandra, and Dynamo-shaped stores. The idea is simple; the details (virtual nodes, bounded loads, rebalancing) are where teams actually lose sleep.

The naive problem

Modulo hashing (hash(key) % N) is easy until N changes. Add a worker and almost every key moves — a thundering herd of cache misses and shard migrations.

Consistent hashing maps keys and nodes onto a ring. When a node leaves, only keys near that node on the ring need to move — not the whole keyspace.

Virtual nodes

One physical machine as a single point on the ring is a hotspot magnet: remove it and its entire arc lands on one successor.

Virtual nodes (vnodes) spread each physical worker at many points on the ring:

The 150 heuristic

Cassandra's default of ~150 vnodes per host is a well-studied compromise — enough spread to avoid hot successors, not so many that metadata overhead dominates. Tune for your skew, not for folklore.

What to watch in production

Rebalance cost
owns: migration bandwidth
measure keys moved per topology changethrottle background transfers
A ring change during peak traffic without rate limits is an outage.
Hot keys
owns: skew
salting / sub-shardingseparate hot-key cache tier
Hashing doesn't fix popularity — it only spreads *average* load.

When you're building membership + routing, pair consistent hashing with a gossip layer (see SWIM gossip) so the ring view converges without a single coordinator.

Comments
Loading comments…