How do you invalidate cached data?
Assesses fundamental understanding of Caching Strategies conventions, runtime behavior, and memory/performance considerations.
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
Invalidation is the hardest part of caching. Options, often combined:
- TTL expiry: every entry has a lifetime; simple and self-healing, but data can be stale until it expires. Use short TTLs for volatile data and longer for stable data.
- Explicit delete or update on write: after committing to the database, delete the cache key so the next read reloads it. Simpler and race-safer than updating in place.
- Versioned keys: include a version or content hash in the key so old entries become unreachable, then let them expire.
- Event-driven invalidation: publish a change event and have caches evict affected keys or tags.
- Cache tags or surrogate keys: group entries so a single purge clears a whole logical set.
await db.update(...);
await cache.del(`user:${id}`);
Prefer delete-on-write over update-on-write to avoid inconsistent overlapping writes, and always keep a TTL as a backstop in case an invalidation message is lost. Measure hit rate and staleness; invalidation bugs are subtle and usually appear 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.