How do you keep a cache consistent with the database?
Interviewer Expectations for this Question
01
Core Competency
Assesses fundamental understanding of Caching Strategies conventions, runtime behavior, and memory/performance considerations.
02
Evaluation Criteria
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
Comprehensive Model Answer
Verified Solution
Perfect consistency is not achievable without giving up caching; aim for bounded staleness and correct behavior.
Practical rules:
- On write, commit to the database first, then delete the cache key. Deleting is safer than updating because concurrent writers can otherwise interleave stale values.
- Use a TTL as a backstop so any missed invalidation self-heals.
- For read-modify-write races, use a short delay before the second delete (double delete) or a versioned key so stale writes cannot overwrite newer data.
- Consider write-through when reads must immediately reflect writes.
- For cross-service data, publish change events and let interested caches evict.
1. UPDATE db
2. DEL cache:user:42
3. next read repopulates from db
A known race: reader misses, reads old DB value, writer updates DB and deletes cache, then the reader writes its stale value. Versioned keys or delayed double delete mitigate it. Document the accepted staleness window and test under concurrency.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.