Why this keeps showing up
Consistent hashing is a foundational way to place data across a cluster. Thousands of explainers exist; many stay academic. This page is interview-focused: the problem, the ring, virtual nodes, hotspots, and when to go deep vs name the store.
Modulo remaps on add/remove.
Hash → walk clockwise to node.
Many points per physical node.
Deep for infra; name it for Dynamo/Cassandra.
Build intuition: TicketMaster-style sharding
Start simple: one database, clients fetching events. Success means load — you shard across multiple databases. Question: which events live on which instance?
First attempt: simple modulo hashing
Hash the event id, then modulo the number of databases:
database_id = hash(event_id) % number_of_databases
# With 3 DBs:
# Event 1234 → hash(1234) % 3 = 1 → DB 1
# Event 5678 → hash(5678) % 3 = 0 → DB 0
# Event 9012 → hash(9012) % 3 = 2 → DB 2
Add a fourth DB and switch to % 4. Production lights up — not only the new box, every box. Changing N remaps almost every key. Event 1234 that lived on DB 1 may now land on DB 0 and must move. Massive unnecessary migration, load spikes, slow or missing reads.
Remove a failed DB (% 3 → % 2) and you get the same remapping storm.
Consistent hashing: the ring
Arrange keys and nodes in a circular hash space (a “hash ring”). Toy size: 0–100. Real rings are often 0 … 2³²−1 — same idea.
- Place DB nodes on the ring (e.g. at 0, 25, 50, 75).
- Hash the event id to a point on the ring.
- Walk clockwise until you hit a DB — that’s the owner.
Adding a node
Add DB5 at position 90. Only keys between the previous neighbor and 90 move (they used to go to the next clockwise node). Everything else stays. Roughly a fraction of one node’s arc — not ~100% of the cluster.
Removing a node
If DB2 fails, only its keys move — to the next clockwise neighbor. Other arcs unchanged.
Virtual nodes
Without vnodes, a failed node dumps its entire arc onto one neighbor (2× load). Fix: place each physical DB at many points — hash DB1-vn1, DB1-vn2, … — so virtual nodes intermix around the ring.
On failure, DB2’s vnodes hand off to different neighbors. On add, the new node’s vnodes are scattered, so it steals small chunks from many peers — not one overloaded neighbor.
Hot spots (still a thing)
Vnodes balance key placement, not traffic. A viral event key can still melt one node. Consistent hashing alone doesn’t fix that.
- Read replicas — copy hot keys; load-balance reads (most common).
- Key salting —
event:{id}:{0..9}so shards scatter; aggregate on read. - Adaptive rebalancing — move hot ranges (ops-heavy; some stores do this automatically).
Data movement in practice
The ring says where data should live — it doesn’t teleport terabytes. Production systems pair placement with replication: fail over to a replica (Raft / quorum) so a crash doesn’t require a full reshuffle. Bulk movement happens mainly on planned membership changes (add capacity, restore replication factor) — and consistent hashing keeps that fraction bounded.
Where it shows up
Same idea for databases, caches, brokers, or sticky app servers:
- Cassandra — tokens / vnodes on a ring.
- DynamoDB — partition placement inspired by the Dynamo paper (internals not a user-facing ring).
- CDNs — which edge owns a cache key.
- Not always a ring — Redis Cluster uses fixed hash slots (
CRC16 % 16384). Simpler mental model; rebalance is coordinated differently. Worth naming as a trade-off.
When to use it in an interview
Most product designs: “We’ll use DynamoDB / Cassandra — they distribute partitions (consistent hashing under the hood).” Done.
Go deep when the prompt is infrastructure: design a distributed cache, database, or broker from scratch. Be ready for:
- Why the ring beats modulo for add/remove
- Virtual nodes for even failure/add load
- Hot keys vs structural imbalance
- How replication avoids moving data on every crash
Hash ring walkthrough
Virtual nodes intuition
More vnodes → smoother load, more metadata. Typically hundreds per physical node in cache rings.
Failure modes to mention
Call out at least one dependency failure (DB down, cache stampede, queue lag, region outage) and your mitigation (timeouts, retries with jitter, degraded mode, circuit breaker).
Cost and performance levers
Interview Q&A by level
Practice saying these out loud for consistent hashing. Interviewers grade clarity and judgment more than buzzwords.
Match depth to the bar: define → trade off → operate. Don't dump principal answers in an entry-level screen.
Wrapping up
Consistent hashing solves a simple-sounding problem: place data across servers while keeping remapping bounded when servers change. Circle + walk clockwise. Built into systems you already name on the whiteboard.
- Default story: hash ring + virtual nodes.
- You usually don’t implement it — you recognize it.
- Save the deep dive for infra-heavy prompts.
Using this for live fan-out? See Real-time updates for protocol choice and the two-hop model.