Interview questions

Interview questions (with the counter-questions you'll get)

Q1. What is consistent hashing, and why is it needed?

They're testing: the core idea.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** With hash mod N, changing N remaps most keys, causing cache misses or massive data movement. Consistent hashing places servers and keys on a ring and assigns each key to the next server clockwise, so adding or removing a server only moves about 1/N of keys, all to or from the changed server.
3
4**Counter-questions:**
5- *"What moves when a server fails?"* → Only its keys, to the next server clockwise (or spread over many with virtual nodes).
6
7**Trap:** explaining the ring without saying what problem it solves.

Q2. Why do we need virtual nodes?

They're testing: the practical refinement.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** With one point per server, arcs are random lengths, so load is uneven and a failed server's load lands on one neighbour. Many points per server average out the arcs, spread a failed server's keys across many others, and let you weight bigger servers with more points.
3
4**Counter-questions:**
5- *"How many?"* → Enough to make load even for your server count, typically tens to hundreds per server; measure the spread.
6
7**Trap:** not knowing the failure-spreading benefit.

Q3. How do you look up a key's server efficiently?

They're testing: implementation.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Keep sorted server positions; hash the key; binary search for the first position greater than it, wrapping round. O(log n) in the number of ring points. Use a stable hash shared by all clients.
3
4**Counter-questions:**
5- *"Why not Python's hash()?"* → It's randomised per process, so clients would disagree.
6
7**Trap:** a linear scan of all servers.

Q4. How does replication work with consistent hashing?

They're testing: Dynamo-style design.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Walk clockwise from the key and take the next N distinct physical servers, skipping virtual nodes of already-chosen servers and preferably servers in the same rack or zone. Combine with quorum reads and writes, and hinted handoff when a replica is temporarily down.
3
4**Counter-questions:**
5- *"What breaks if you don't skip duplicates?"* → Several replicas land on one machine, so one failure loses the data.
6
7**Trap:** "the next three points".

Q5. Consistent hashing vs fixed hash slots (like Redis Cluster)?

They're testing: knowing alternatives.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Fixed slots hash keys into a fixed number of slots (Redis uses 16,384) and assign slots to nodes; rebalancing moves whole slots, which is simple to reason about and track. The ring needs no fixed slot count and moves keys implicitly as nodes join. Both limit movement to a small share; slots make the mapping explicit and easy to migrate.
3
4**Counter-questions:**
5- *"Downside of slots?"* → The slot count caps how finely you can split, and the slot map must be distributed to clients.
6
7**Trap:** claiming Redis Cluster uses a hash ring.

Q6. What is rendezvous hashing?

They're testing: breadth.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** For each key, score every server with hash(key, server) and pick the highest. It moves only about 1/(N + 1) of keys when a server is added, spreads evenly without virtual nodes, and gives replicas as the top-N scores, but lookups are O(N).
3
4**Counter-questions:**
5- *"When prefer it?"* → Small server counts and when simplicity matters, like picking a cache server in a PoP.
6
7**Trap:** not knowing it exists.

Q7. You add 4 cache servers to 4. What happens, and how do you soften it?

They're testing: operational thinking.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** About half the keys move (4 of 8 shares), so about half of lookups miss at once and hit the database. Soften it by adding servers gradually, warming them (copy hot keys or dual-read from old owners during a transition), using request coalescing and stale-while-revalidate, and doing it before peak traffic.
3
4**Counter-questions:**
5- *"How many move adding one server to 4?"* → About a fifth.
6
7**Trap:** saying "only 1/N moves" when adding several servers at once.

Q8. How do you handle hot keys with consistent hashing?

They're testing: the limits of hashing.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Hashing puts each key on one server, so a very hot key overloads its owner regardless of balance. Use a local in-process cache in front, replicate hot keys to several servers and read from any, or split the key (key#1 ... key#k) and spread requests across the copies (Chapter 13).
3
4**Counter-questions:**
5- *"How do you detect hot keys?"* → Count requests per key with a sketch (Chapter 20) or the cache's own stats.
6
7**Trap:** "virtual nodes fix hot keys".

Q9. How do clients agree on which servers are on the ring?

They're testing: membership.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Through a shared membership source: static configuration pushed to clients, a coordination service (ZooKeeper, etcd), service discovery (Chapter 27), or gossip between nodes as in Dynamo and Cassandra. Brief disagreement during changes causes some misses or misrouted requests, so systems tolerate and repair it.
3
4**Counter-questions:**
5- *"What if two clients disagree?"* → They may read and write different servers briefly; caches tolerate it, databases use versioning and repair.
6
7**Trap:** assuming membership is instantly consistent.

Q10. Where is consistent hashing used in real systems?

They're testing: connecting theory to practice.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Client-side sharding of Memcached, Dynamo-style databases like Cassandra and Riak, load balancers keeping requests for the same key on the same backend (Envoy ring hash and Maglev), caching within CDN PoPs, and partitioning work in stream processing.
3
4**Counter-questions:**
5- *"And where not?"* → Systems with fixed partitions or slots, like Kafka topics and Redis Cluster.
6
7**Trap:** only naming caches.
8
9---
10
11## Practice coverage
12
13Every section in this chapter is tested at least once.
14
15| Section | Tested by |
16|---|---|
17| 28.1 Mod N | Level 1A.1, Level 2.1, Level 2.3, Level 3.1, Q1 |
18| 28.2 Hash ring | Level 1A.2, Level 3.2, Q1 |
19| 28.3 Finding a key's server | Level 2.4, Level 3.2, Q3 |
20| 28.4 Adding and removing | Level 2.2, Level 3.3, Level 5.4, Q7 |
21| 28.5 Virtual nodes | Level 1A.3, Level 1A.4, Level 2.5, Level 3.4, Level 5.2, Q2 |
22| 28.6 Replication | Level 3.5, Level 4, Q4 |
23| 28.7 Where it's used | Level 1B, Level 5.1, Level 5.3, Q5, Q9, Q10 |
24| 28.8 Rendezvous | Level 1A.5, Level 3.5, Q6 |
25
26---

28. Consistent Hashing