System DesignJul 12, 2026 · 2 min
Consistent hashing in five minutes
Why naive modulo sharding falls over, and what the ring fixes.
The problem with hash(key) % N
Modulo sharding works until N changes. Add or remove one server and
almost every key maps to a different node — a full reshuffle, cache
hit rate goes to zero, databases stampede.
The ring
Consistent hashing places both servers and keys on the same hash circle (0 → 2³² wrapping around). A key belongs to the first server clockwise from it.
- Add a server → only the keys between it and its predecessor move
- Remove a server → only its keys move, to the next node clockwise
- On average,
K/Nkeys move instead of nearly all of them
Virtual nodes
Real servers are few, so raw placement is lumpy — one node can own a huge arc. The fix: hash each server to many points on the ring ("vnodes", often 100–200 per node). Load evens out statistically, and a beefier machine can simply get more vnodes.
Where you've already met it
- DynamoDB / Cassandra — partition placement
- Memcached clients (ketama) — cache key routing
- Load balancers — sticky-ish routing without shared state