Caching in System Design Interviews: Invalidation, Staleness, and Surviving the Follow-Ups

Sit in enough system design interviews and you notice that one box shows up in almost every diagram, usually early, usually drawn with real confidence: the cache. That makes sense. Most prompts describe read-heavy systems, caching is the best-known answer to read pressure, and the box takes about two seconds to draw. What took me longer to notice as an interviewer is that the box itself did nothing for candidates in my writeups, because everyone draws it. The grading started a bit later, when I asked some version of "a user updates their profile and immediately refreshes the page, what do they see?", and that one question decided more cache discussions than every technology-choice debate I can remember, combined.

This article opens a series that takes the standard building blocks of design interviews one at a time. The ten failure modes article is the hub, the process-level view of where these interviews go wrong, each failure with a mid-interview tell and a pre-committed guard; the block articles go a level deeper on individual components, and each one follows the same layout on purpose: what the block gets you, the follow-up questions you should expect, how deep you need to go, a guard rule you can commit to before the interview starts, and what the failure looks like to a user. Caching goes first because, in the interviews I've conducted, it was the block candidates reached for the most and were the least prepared to defend.

What the cache gets you

In an interview, a cache does one job: it answers reads from fast memory so the database doesn't have to answer them from disk (or so something expensive to compute, like a rendered feed or an aggregated count, doesn't get recomputed on every request). It's worth having when three conditions line up. Reads have to dominate writes, which the estimation step usually establishes early (feed-style systems commonly land at 100 reads per write or more). The reads have to bunch up on the same popular items, since a cache that sees a different key on every request is just an extra network hop. And some staleness has to be tolerable, because the moment you keep a second copy of data, the copies can disagree.

Candidates state the first two conditions constantly and skip the third, and the third is where every follow-up comes from.

People treat this block like it hides bottomless trivia, so here's how deep you need to go. You do not need Redis command knowledge, eviction-algorithm internals (saying "LRU, and I'd revisit if profiling disagreed" covers it), or a prepared Redis-versus-Memcached comparison; in the debriefs I sat in, none of that ever swung a decision. What you need is an answer to four plain questions about the box you drew: what exactly is in it, keyed by what, who writes it, and when is it wrong.

The follow-ups you should expect

The profile-edit question is the standard one, and there are plenty more like it. You delete a post, does it come back on the next page load? The like count says 41, how wrong is that allowed to be, and for how long? Then the second-order versions: what happens when this cache node restarts empty at peak traffic, and what happens when a very popular key expires at noon?

None of these are gotchas, and I'd encourage you not to hear them as hostility. As I argued in the article on how interviewers tell memorization from understanding, interviewers find out what you understand by perturbing what you gave them rather than by asking directly, and the cache is the easiest component on the board to perturb, because its whole reason for existing is a second copy of the data, and second copies can go wrong. A memorized "we'll add a cache to reduce database load" has nothing prepared for the perturbation. An understood one degrades gracefully: you may not have planned for the exact question, but you can reason your way to an answer from the pattern you chose.

What the failure looks like to a user

Staleness sounds abstract right up until you say it concretely, and saying it concretely is most of the graded skill. You edit a comment, refresh, and your old text comes back. You delete something embarrassing and it reappears on the next page load. You change your shipping address, and checkout uses the old one without telling you, which is the version of this failure that gets somebody paged on a weekend. Same mechanism in all three, wildly different severity, and the difference lives entirely in what the data means to the person reading it.

That framing, "what does the user see, and do we care", is the thing to hold onto for the whole cache discussion, because every mechanism choice below is a different answer to it.

Cache-aside, write-through, and write-back, without the flashcards

• Cache-aside (the default, and probably what your diagram means even if you didn't say so): the application checks the cache first, on a miss it reads the database and fills the cache, and writes go straight to the database. The cached copy is wrong from the moment of a write until you explicitly invalidate it or its TTL expires. Simple, and the staleness window is at least explicit.
• Write-through: writes go to the cache and the database together, so the cached copy stays fresh. You pay with write latency, and with caching plenty of entries nobody reads again.
• Write-back (sometimes write-behind): writes land in the cache and flush to the database asynchronously. Writes get fast, and a crash before the flush loses data. In an interview this is a niche pick (counters, metrics, things you can afford to lose a few seconds of), and if you choose it, say the data-loss risk out loud before the interviewer does.

Interviewers don't go as deep on this as the flashcard decks suggest. Nobody in the debriefs I sat in cared whether a candidate could recite all three; what sank people was drawing a cache with no idea which pattern it was, because "who writes this box" is the first follow-up and the pattern is the answer. One pattern chosen and defended beat three patterns named and none defended, every time I watched it play out.

TTL is the unglamorous default

Cache invalidation is one of the two famously hard problems in computer science (the old Phil Karlton line), along with naming things, and off-by-one errors. The joke has survived because it's true: explicit invalidation means every write path in your system has to know about every cached key derived from the data it touches, and the one place you forget leaves you with staleness that never fixes itself.

Which is why the unglamorous answer, a TTL, makes such a strong interview default. Expiring every entry after a fixed window is crude, but it converts "this cache might be wrong forever" into "this cache is wrong for at most five minutes", it needs no bookkeeping, and it heals every mistake on a schedule. The move that came across as senior in the interviews I've conducted was pairing the two: TTL as the backstop everywhere, plus targeted invalidation on the handful of writes where users would actually notice. "Cache-aside with a five-minute TTL, and I'll invalidate a user's own profile key on their own writes so people always read their own edits" is one sentence, and it answers the standard follow-up before it gets asked.

Staleness tolerance is a requirements question

The best cache defenses I watched didn't start at the cache. They started around minute three, back in requirements, when the candidate asked some version of "how fresh do these reads need to be?" and pinned the answer down per feature: your own edits, zero tolerance; someone else's like count, minutes are fine; search results, somewhere in between; anything touching money, treat it as zero until told otherwise.

Do that and the cache section largely answers itself, because the staleness budget picks the mechanism. A budget of zero means invalidate on write, or write through, or don't cache that read path at all. A budget in minutes means TTL and move on. It also changes how the follow-up lands: instead of improvising a tolerance under pressure, you point back at a requirement you established twenty minutes earlier. Practices vary between interviewers, as always, but I never saw a candidate hurt by asking about freshness during requirements, and I watched a fair number get saved by it.

Stampedes and hot keys

Two more failure modes show up one follow-up deeper, and they're what interviewers reach for when the staleness discussion went well.

The stampede: a popular key expires, and every request it was absorbing misses at the same moment, so the database takes the whole herd at once, at peak, which is when the popular key was popular. Naming the mitigations is enough here: jitter your TTLs so keys don't expire in sync, let one request do the refresh while the others briefly serve the stale value, and background-refresh keys you know are hot so they never expire cold.

The hot key: one identifier so popular that the single cache node holding it saturates (the celebrity problem; any partitioned cache has some key it would rather not be holding when someone famous posts). Mitigations to name: keep copies of that key on several nodes, or put a tiny in-process cache in front of the shared one for the top handful of keys.

Again, naming the problem and one plausible mitigation is enough. Nobody expects working code for any of it at a whiteboard, and volunteering the failure unprompted ("the thing I'd watch here is a popular key expiring under load, so I'd jitter the TTLs") goes over better than any amount of recited trivia.

The one-sentence save

Sometimes the follow-up lands and you realize you drew the box on autopilot. You can practice the way back, because it's the same four steps every time even though the details change with the design: the mechanism, how stale it can get, what the user sees, and what you'd do about it. "This is cache-aside with a five-minute TTL, so this read can be up to five minutes stale, which means a user might not see their own edit, and that's not acceptable, so I'd invalidate that key on the write path and keep the TTL as a backstop." One breath, four parts, and it demonstrates the exact reasoning the question was probing for.

The answers that sank interviews sounded nothing like that, and it helps to recognize them ahead of time so you can steer away from them: "the cache would handle that" (the cache is the thing in question, so it can't also be the reassurance), a long unnarrated silence, or a bespoke invalidation scheme invented under pressure that contradicts the diagram it's meant to defend. Needing a beat to think was never the issue; say so and take it.

And the strongest version is easy: say the sentence unprompted, while you're drawing the box. Interviewers steer toward the gaps they can see, and a gap you've already closed out loud usually stops being interesting to probe.

The guard rule

Every article in this series ends with one rule you commit to before the interview starts, so you don't have to rely on in-the-moment judgment, and this one comes straight from the failure modes hub: draw nothing you can't survive two follow-up questions on. The hub compressed the whole cache topic into that sentence, being ready for the invalidation question and the staleness question, and this article has been the unpacking.

Two, specifically, because the first follow-up is usually answerable from the name of the pattern, and the second is where memorized material runs out. Before the marker touches the board, run the private pre-flight: what exactly is in this box and keyed by what, what happens when the underlying data changes, and what happens when the box disappears. If you can't answer, don't draw it yet. A design with no cache plus a sentence about when you'd add one is completely fine, while a cache you can't defend is a lot worse, for the same reason I gave in the article on passing these interviews without scale experience: a boring design you fully understand holds up under probing far better than an impressive one you half remember.

The defense itself is a spoken skill, so the practice has to be spoken. Free covers most of it: record yourself doing a full timed prompt and grade the tape (the solo practice routine works unchanged here, just add "what happens when the data changes" to the rubric), or hand a friend the interviewer role with instructions to ask that question at every single box. And if you'd rather have the invalidation question arrive without scheduling a human to ask it, that's part of what we build at Preppable. Nearly everyone's first cache defense is shaky, the improvement between the first attempt and the third tends to be fast, and this particular block repays the practice more than any other, because it's waiting in nearly every prompt you'll be handed.