What are the Main Cache Invalidation Strategies?
Compare TTL, explicit, and event-based cache invalidation strategies, their trade-offs, and when to combine them.
Expected Interview Answer
Cache invalidation removes or refreshes stale cached data using three common strategies: TTL-based expiration (entries auto-expire after a fixed time), explicit invalidation (the application deletes or updates the key when the source data changes), and event-based invalidation (a change stream or pub/sub message triggers invalidation across all cache nodes).
TTL expiration is the simplest — every cached entry gets a time-to-live and is treated as stale once it passes, bounding staleness without any coordination, but it can still serve outdated data until expiry. Explicit invalidation deletes or overwrites the specific cache key the moment the underlying row changes, typically right after a database write in the same request, giving near-immediate consistency but requiring the application to remember every cache key tied to every piece of data it writes. Event-based invalidation decouples writers from cache nodes by publishing a change event (often from a database change-data-capture stream) that all interested caches subscribe to and act on, which scales to multiple cache instances and services but adds infrastructure and a small propagation delay. Real systems usually combine a TTL as a safety net with explicit or event-based invalidation for freshness.
- TTL: simple, no coordination required, bounds worst-case staleness
- Explicit invalidation: near-immediate consistency after a write
- Event-based: scales across many cache nodes and services
- Combining strategies gives both freshness and a staleness safety net
AI Mentor Explanation
A stadium's printed matchday programme lists the starting eleven and is only reliable until the toss, after which it is simply treated as stale — that is TTL expiration, a fixed shelf life with no active correction. A team manager who spots a late injury change and personally runs to tell the announcer to update the lineup board is explicit invalidation, fixing the exact stale entry the moment it is known wrong. A stadium-wide PA system broadcasting 'lineup changed' so every scoreboard, app, and screen refreshes at once is event-based invalidation, propagating one change to every dependent display.
Step-by-Step Explanation
Step 1
Set a baseline TTL
Every cached entry gets an expiration time so worst-case staleness is bounded even without any active invalidation.
Step 2
Invalidate explicitly on write
Immediately after a database write, delete or overwrite the specific cache key that corresponds to the changed row.
Step 3
Publish a change event
For multi-node caches, emit a change event (e.g. from a CDC stream or pub/sub) that all cache instances subscribe to.
Step 4
React and refresh
Each cache node consumes the event and deletes or updates its local copy of the affected key.
What Interviewer Expects
- Naming and explaining at least TTL and explicit invalidation clearly
- Understanding the trade-off between staleness window and coordination complexity
- Awareness that multi-node caches need event-based propagation, not just local deletes
- Recognition that real systems layer strategies rather than pick just one
Common Mistakes
- Claiming caches always know instantly when source data changes
- Forgetting to invalidate related keys (e.g. a list cache) after a single-row update
- Treating TTL alone as sufficient for data that changes unpredictably
- Ignoring propagation delay in event-based invalidation across regions
Best Answer (HR Friendly)
“There are three main ways to invalidate a cache: let entries simply expire after a fixed time (TTL), have the application delete or update the specific key right when the data changes, or broadcast a change event that all cache servers listen for and react to. Most real systems combine a TTL as a safety net with explicit or event-based invalidation so data stays fresh without needing perfect coordination everywhere.”
Code Example
-- 1. Update the source of truth
UPDATE Products
SET price = 24.99
WHERE product_id = 55;
-- 2. Application immediately invalidates the cache key
-- cache.delete("product:55")
-- (next read will miss and repopulate from the database)
-- 3. Optionally, a change-data-capture stream also publishes
-- an event so other cache nodes/services invalidate too:
-- publish("product.updated", { product_id: 55 })Follow-up Questions
- How would you invalidate a cached list or aggregate when one underlying row changes?
- What is cache stampede and how does it relate to TTL expiration?
- How does change-data-capture (CDC) help with event-based invalidation?
- How would you choose a TTL for data with unpredictable update frequency?
MCQ Practice
1. Which invalidation strategy relies purely on a fixed time limit with no active correction?
TTL expiration simply treats an entry as stale after a set duration, without any signal telling it the data actually changed.
2. Why is event-based invalidation useful for systems with multiple cache nodes?
A broadcast change event lets every cache node react to the same update, which local-only invalidation cannot achieve across distributed caches.
3. What is a common real-world approach to cache invalidation?
Layering a TTL as a fallback with explicit or event-driven invalidation balances freshness with resilience against missed invalidations.
Flash Cards
What is TTL-based invalidation? — Cached entries automatically expire after a fixed time, regardless of whether the data actually changed.
What is explicit invalidation? — The application deletes or updates a specific cache key right when the underlying data changes.
What is event-based invalidation? — A published change event notifies all cache nodes to invalidate the affected key, useful for multi-node caches.
Why combine strategies? — A TTL bounds worst-case staleness while explicit/event-based invalidation gives near-immediate freshness.