Consistent Hashing
Maps keys to nodes on a ring so adding/removing a server only moves ~1/N keys — not full rehash.
Interview tip Lead with a 30-second definition, then one real system example and name 2–3 designs where Consistent Hashing is non-negotiable.
① What it is (30 seconds)
Maps keys to nodes on a ring so adding/removing a server only moves ~1/N keys — not full rehash.
② How it works in system design
Hash nodes and keys onto ring. Key walks clockwise to first node. Virtual nodes balance load. Used for distributed cache, Dynamo-style storage, load balancers.
Typical placement
Client→Edge / Gateway→Consistent→Services→Data stores
③ Concrete system design example
Scenario: Distributed cache cluster: 100 Redis shards. Add shard 101 — only keys between predecessor and new node migrate, not entire cache flush.
④ Important interview Q&A
| Question | Answer |
|---|---|
| Why not mod N hashing? | mod N reshuffles almost all keys when N changes — cache avalanche. |
| Virtual nodes? | Each physical node has many ring positions — evens out skew when few servers. |
| Who uses it? | Redis Cluster, Cassandra partitions, CDNs, memcached proxies. |
⑤ Seen in these system designs
- Distributed Cache — shard routing
- Rate Limiter — counter shards
- Shared Counter — counter shards
In interviews, after explaining the concept, say: "This shows up directly in …" and link two designs.
⑥ Revision checklist
- Ring intuition
- vs mod N
- Virtual nodes
- Minimal key movement on rebalance