Interview › Databases & Caching
How do you decide what to cache and what not to cache?
Databases & Caching · Advanced level
Answer
I cache data that is frequently read, expensive to fetch or compute, reasonably small, and tolerant of staleness. I avoid caching rapidly changing, sensitive, authorization-heavy, cheap, or strict-consistency data.
Technical explanation
Good cache candidates are hot, expensive, small, and stale-tolerant.
Bad candidates are rapidly changing, sensitive, huge, cheap to query, or strict-consistency data.
Authorization-heavy data requires special care because stale permissions are a security risk.
Hands-on example
Decision examples:
Cache product category list: yes.
Cache payment balance: no, read primary.
Cache user permissions for 1 hour: risky; prefer short TTL or token/revocation design.
Check how well your resume matches the role with our free resume checker— match score, ATS check, and the skills you're missing.
More Databases & Caching interview questions
- What is Amazon RDS, and what does it manage for you versus self-managed databases?
- What database engines does RDS support?
- What is the difference between RDS and Aurora?
- What is Multi-AZ in RDS, and how does automatic failover work?
- How long does an RDS Multi-AZ failover typically take, and what triggers it?
- What is the difference between Multi-AZ and a read replica?
- When would you use a read replica, and can it become a standalone database?
- Can a read replica be in a different region, and why would you do that?