You add a cache and stale data starts appearing. How do you think about invalidation?
What they are really testing: Whether you can reason about consistency trade-offs rather than reaching for a longer or shorter TTL. They also want to hear about the failure modes caching introduces, like stampedes.
A real interview question
You add a cache and stale data starts appearing. How do you think about invalidation?
What most people say
drag me
“I would lower the TTL so the data refreshes more often.”
It trades one problem for another without deciding anything: shorter TTL means more misses and more database load, and it still serves stale data for the whole window. It also does nothing about the actual cause, which is usually a write path that never invalidates.
The follow-ups they ask next
What exactly is single-flight and why does it matter?
On a miss, one caller computes the value while others wait for that result rather than each querying. It turns a thousand simultaneous database queries into one, which is the difference between a blip and an outage.
Another service writes the same table directly. How do you handle invalidation?
Either make cache invalidation a consequence of the write via change data capture or an event, or accept TTL-bounded staleness. Relying on every writer remembering to call your invalidation is a guarantee of future bugs.
How do you avoid a cold cache causing an incident after each deploy?
Keep the cache external to the pod so deploys do not empty it, and warm critical keys before taking traffic. An in-process cache means every deploy is a thundering herd.
When would you say no to adding a cache at all?
When correctness demands are strict and the load is manageable, or when the query is cheap and the cache adds a consistency problem plus a new dependency for little benefit. A cache is a distributed system you now operate.
What the interviewer is listening for
- Starts from the staleness budget
- Hunts for write paths that bypass invalidation
- Knows stampede and single-flight
- Treats a cache as a new operational dependency
What sinks the answer
- Only adjusts TTL
- Assumes all writes go through one path
- No awareness of stampedes
- Adds caching reflexively
If you genuinely do not know
Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.
“First [what staleness is acceptable, since that is a product decision]. TTL alone [guarantees staleness for its window], explicit invalidation [is fresher but fails when a write path forgets], so I look for [batch jobs, admin tools, migrations, other services writing the same table]. Default is [short TTL as a safety net plus explicit invalidation]. Then handle [stampede with jitter and single-flight] and [cold start after deploys].”
Keep going with databases
Mid
You need to rename a heavily-used database column with zero downtime. How?
Senior
You scale a service from 10 to 100 pods and the database starts failing. Why, and how do you fix it?
Senior
Design a CI/CD system for 15 microservices owned by 4 teams deploying several times a day.
Senior
Design an observability stack for a system where nobody can currently answer why a request was slow.
Senior
Leadership asks you to prove the platform investment is working. What do you measure?
Senior
You inherit 200 Jenkins jobs with no documentation and are asked to migrate to a modern CI system. How do you approach it?
Knowing the answer is not the same as recalling it under pressure
Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.
Start free