Asked out loud, answered out loud. Read the answer, then say it in your own words.
Where would you place a cache in a system?
There are three honest answers and they are not alternatives — most real systems use all three. Client-side, in the browser, for static assets the user already has. Application-level, in Redis or Memcached, for sessions and repeated queries. And database-level, for the results of expensive queries that would otherwise be recomputed per request.
The follow-up that catches people: each layer has a different invalidation story, and the one nearest the user is the one you can least easily reach.
What is a cache stampede, and how do you prevent one?
A popular key expires, and every request that wanted it misses at the same instant — so the database receives in one moment the load the cache was absorbing all day. The fixes are early expiration (refresh just before expiry, while the old value still serves), request coalescing — a single flight, where one request recomputes and the rest wait on it — and pre-warming keys you know are hot.
Say the number out loud if you have one: single-flight turns a 3,800-query stampede into one query.
On a write, do you invalidate the cache entry or update it?
Invalidate, by default. Updating means writing the same fact twice through two different paths, and the moment those paths can interleave you have a cache that is confidently wrong — which is worse than a cache that is empty. Deleting the entry costs one recomputation; writing it wrong costs you the rest of the day.
This is the whole unit in one question: the performance costume, and the correctness problem underneath.
Design a distributed cache.
Four decisions, in order. Spread keys with consistent hashing so adding a node moves a slice rather than everything. Pick an eviction policy — LRU is the common default, and it assumes recent access predicts future access. Replicate entries so one node failing is a slowdown, not an outage. Then choose write-through or write-back, which is really a choice about what you are willing to lose in a crash.
Name the tradeoff on each of the four and you have answered it; name none and you have listed components.
What is a hot key, and why does adding nodes not fix it?
One key so much more popular than the rest that the single node owning it saturates while the cluster average looks idle. Adding nodes does nothing, because the key still hashes to exactly one of them. The fixes all break the one-key-one-node mapping: replicate the key to several nodes and read from a random one, add a small per-process local cache in front so most reads never leave the app, or shard the key itself into key:0 … key:N and pick one at random.
