Cache data that is read far more often than it changes and is expensive to produce. For invalidation, prefer a short time to live for anything that can be slightly stale, and explicit invalidation on write for anything that cannot. Key the cache by everything that varies the result, including tenant and permissions, and treat the cache as disposable: the system must stay correct when it is empty.
Why interviewers ask this
Caching is where correctness bugs and outages both come from, so the interviewer is probing for judgment rather than knowledge of Redis commands. They want the read to write ratio as the selection criterion, an explicit invalidation strategy, awareness that cache keys can leak data between users, and the discipline to treat the cache as an optimization the system can survive without.
How to structure your answer
- Give the criterion: read heavy, expensive, tolerably stale.
- Choose between a short time to live and invalidation on write.
- Warn about cache keys leaking data across users.
- State that the system must work with a cold cache.
Example answer
I look for three properties: read far more than written, expensive to compute, and tolerant of being slightly stale. If it fails the last one, like an account balance, I would rather it be slow and right. For invalidation my default is a short time to live, because it is self healing; if a bug means I miss an invalidation, the problem clears itself in sixty seconds instead of living forever. Where staleness genuinely is not acceptable I invalidate in the same code path as the write and accept the extra coupling. The thing I am most careful about is the key. Anything that varies the result goes in it, especially the tenant or user id, because the worst caching bug I have seen was a response cached at the CDN that included a personalized header, and one customer briefly saw another customer's name. And I always test with the cache flushed, because if the system falls over cold, it is not a cache, it is a dependency.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- How would you prevent a stampede when a hot key expires?
- Where would you put the cache: in process, Redis or the CDN?
- How do you measure whether a cache is actually helping?
Related software engineer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions