Interview questions

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

Q1. What is a cache stampede, and how do you prevent it?

They're testing: a classic failure mode and real fixes.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** When a hot key expires, many requests miss at once and all query the database for the same data. I'd prevent it with single flight: one request loads the value while others wait for its result, using a per-key lock in-process and a short-lived distributed lock or lease across servers. Alternatives are serving the stale value while one request refreshes it, and refreshing early with a small random probability before expiry.
3
4**Counter-questions:**
5- *"What if the request holding the lock crashes?"* → The lock needs an expiry so others aren't stuck, and waiters should have a timeout after which one of them retries.
6- *"Is single flight enough with 100 app servers?"* → An in-process lock limits it to one load per server, so up to 100. For one load overall, use a distributed lock or lease in the cache.
7
8**Trap:** "just increase the TTL".

Q2. What's the difference between cache penetration, stampede and avalanche?

They're testing: precise vocabulary.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Penetration is requests for data that doesn't exist, so nothing is ever cached and every request reaches the database. A stampede is many simultaneous misses on one popular key. An avalanche is many keys missing at once, from mass expiry or the cache going down. Fixes: negative caching and Bloom filters for penetration; single flight and early refresh for stampedes; jitter, replicas, warming and database protection for avalanches.
3
4**Counter-questions:**
5- *"Which is the most dangerous?"* → An avalanche from the whole cache going down, because it hits every key at once. Design the database's protections assuming the cache can vanish.
6
7**Trap:** using the terms interchangeably.

Q3. How do you protect against requests for non-existent data?

They're testing: penetration defences, including security.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Cache "not found" results with a short TTL, put a Bloom filter of valid IDs in front so impossible IDs are rejected without a lookup, validate ID formats, and rate-limit clients making many not-found requests.
3
4**Counter-questions:**
5- *"Why a short TTL for negative entries?"* → So a product created a moment later becomes visible quickly.
6- *"Bloom filters have false positives. Problem?"* → A false positive just lets a request through to the normal path; it never blocks a real ID. That's fine.
7
8**Trap:** only suggesting rate limiting.

Q4. One cache node is overloaded while the others are idle. Why, and what do you do?

They're testing: hot-key awareness.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Probably a hot key: one key with huge traffic always maps to the same node, and sharding can't spread a single key. I'd confirm with per-key metrics or the cache's hot-key tooling, then add a short-TTL in-app cache for the top keys, keep several copies of the hot key under different names that land on different nodes, or add read replicas for that node.
3
4**Counter-questions:**
5- *"What's the cost of copies?"* → Every write must update or delete all copies, and copies can briefly differ. Fine for read-heavy data like a product page.
6
7**Trap:** "add more nodes".

Q5. How would you design a distributed cache?

They're testing: sharding, replication and failure handling.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Shard keys across nodes with hash slots or consistent hashing, so adding or removing nodes moves only a small fraction of keys. Give each node a replica for failover. Route through a cluster-aware client or proxy. Keep nodes below full for headroom, add jitter to TTLs, and treat the cache as a copy: losing it must slow things down, not lose data.
3
4**Counter-questions:**
5- *"Why not hash mod N?"* → Changing N remaps almost every key, causing an avalanche.
6- *"How do multi-key operations work?"* → Only easily for keys on the same node; use hash tags to co-locate related keys.
7
8**Trap:** designing without replicas or without thinking about resizing.

Q6. How does a cache cluster handle a node failure?

They're testing: failover realism.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** The node's replica is promoted to primary, and clients update their slot map. Replication is usually asynchronous, so the last few writes may be lost, which is acceptable for a cache. While failover happens, requests for those slots may miss or fail briefly, so the app needs timeouts and must fall back to the database with protections in place.
3
4**Counter-questions:**
5- *"What if there's no replica?"* → That node's keys are gone; its share of traffic hits the database until the cache refills. That's an avalanche for those keys.
6
7**Trap:** assuming no data is ever lost in a failover.

Q7. What is cache warming, and when do you need it?

They're testing: operational practice.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Pre-loading the cache with expected hot data before traffic arrives: before a known event like a sale, after a restart, when adding nodes, or after a deploy that changes key formats. Warm from yesterday's top keys or a product list, or by replaying sampled traffic, and shift traffic gradually. Use jittered TTLs so warmed keys don't expire together.
3
4**Counter-questions:**
5- *"Why not warm everything?"* → It takes time and memory, and evicts the keys that are actually hot.
6
7**Trap:** forgetting jitter on warmed keys.

Q8. Explain Cache-Control, ETag and 304.

They're testing: HTTP caching basics.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Cache-Control tells browsers and CDNs whether and how long to keep a response: max-age for freshness, s-maxage for shared caches, private for user-specific data, no-store for sensitive data, no-cache to always revalidate. An ETag is a fingerprint of the content; when a cached copy is stale, the client sends If-None-Match with it, and if nothing changed the server replies 304 Not Modified with no body.
3
4**Counter-questions:**
5- *"How do you update a file that browsers cached for a year?"* → Use versioned file names, so a change is a new URL.
6- *"no-cache vs no-store?"* → no-cache allows storing but requires revalidation before each use; no-store forbids storing at all.
7
8**Trap:** thinking no-cache means "don't cache".

Q9. What would you monitor on a cache?

They're testing: operational maturity.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Hit rate overall and per key prefix, evictions, memory use, latency percentiles, per-node load to spot hot keys, connection errors and timeouts, and database query rate alongside, since that's what the cache is protecting. I'd alert on sudden hit-rate drops, uneven node load and eviction spikes.
3
4**Counter-questions:**
5- *"Hit rate fell from 95% to 60% right after a deploy. First guess?"* → The deploy changed key names or formats, so old entries no longer match.
6
7**Trap:** monitoring only memory.

Q10. The cache cluster went down during the sale. Walk me through what happens and what should protect you.

They're testing: designing for the worst case.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Every request misses and heads to the database, which can't handle full traffic. Protection should already be in place: timeouts on cache calls so requests don't hang, a circuit breaker that stops waiting on the dead cache, database connection limits, rate limiting and load shedding to keep the core path alive, a small in-app cache for the hottest items, and degraded pages. Then bring the cache back with replicas or persistence and warm it before restoring full traffic.
3
4**Counter-questions:**
5- *"How do you test this?"* → Deliberately kill cache nodes in a staging environment under load, and measure what the database and users see (Chapter 29).
6
7**Trap:** "the cache won't go down".
8
9---
10
11## Practice coverage
12
13Every section in this chapter is tested at least once.
14
15| Section | Tested by |
16|---|---|
17| 13.1 Stampede | Level 1.3, Level 2.1, Level 3.1, Level 4, Q1, Q2 |
18| 13.2 Penetration | Level 1.2, Level 3.2, Level 5.4, Q2, Q3 |
19| 13.3 Avalanche | Level 1.1, Level 1.5, Level 2.2, Q2, Q10 |
20| 13.4 Hot keys | Level 1.4, Level 5.3, Q4 |
21| 13.5 Distributed cache | Level 2.3, Level 2.4, Level 3.3, Level 5.5, Q5, Q6 |
22| 13.6 Warming | Level 5.2, Q7 |
23| 13.7 HTTP caching | Level 3.4, Level 5.1, Q8 |
24| 13.8 Measuring | Level 5.6, Q9 |
25
26---

13. Caching at Scale