What is cache invalidation and what strategies work with Redis?
What cache invalidation is and how TTL, cache-aside, write-through and write-behind work with Redis. Examples, stampede pitfalls and interview answers.
Expected Interview Answer
Cache invalidation is the process of removing or refreshing cached data once the underlying source of truth changes, so clients stop reading stale values; with Redis the common strategies are TTL expiry, write-through, write-behind, and explicit deletion on write (cache-aside).
The hardest part is deciding when a cached entry no longer reflects reality. TTL sets an expiry so entries self-remove after a bounded staleness window. Cache-aside (lazy loading) reads from cache, falls back to the database on a miss, and deletes or updates the key whenever the source changes. Write-through updates cache and database together on every write for strong freshness at higher write cost, while write-behind buffers writes to the database asynchronously for speed at the risk of loss. Redis supports these with EXPIRE/TTL, key deletion, and keyspace notifications, and you must guard against stampedes when many keys expire at once.
- Prevents clients from serving stale data
- TTL bounds staleness automatically
- Cache-aside keeps the cache lazy and cheap
- Write-through maximizes freshness for critical data
- Keyspace notifications let apps react to expiries
AI Mentor Explanation
Cache invalidation is like updating the stadium scoreboard the instant a wicket falls. If the operator forgets, fans keep reading a score that no longer matches the middle. A TTL is like a board that auto-refreshes each over regardless, guaranteeing it is never more than one over out of date even if someone forgets to update it manually.
Step-by-Step Explanation
Step 1
Pick a freshness requirement
Decide how stale data may be; this drives whether TTL alone is enough or you need active invalidation.
Step 2
Choose a read pattern
Cache-aside reads cache first, loads from the database on a miss, and stores the result back.
Step 3
Set a TTL
Use EXPIRE or SET with EX so entries self-remove after a bounded staleness window.
Step 4
Invalidate on write
On every source update, delete or overwrite the cached key so the next read reloads fresh data.
Step 5
Guard against stampedes
Jitter TTLs, use locks or early recomputation so many simultaneous misses don't hammer the database.
What Interviewer Expects
- A clear definition of stale data and the source of truth
- Knowledge of TTL, cache-aside, write-through and write-behind
- Awareness of cache stampede and how to mitigate it
- Redis-specific tools like EXPIRE and keyspace notifications
- Trade-offs between freshness and write cost
Common Mistakes
- Relying only on TTL when strong freshness is required
- Forgetting to invalidate the cache on database writes
- Setting identical TTLs that expire together and cause stampedes
- Confusing eviction (memory pressure) with invalidation (staleness)
- Caching data that changes faster than any useful TTL
Best Answer (HR Friendly)
“Cache invalidation means clearing or updating cached data once the real data behind it changes, so users don't see outdated results. With Redis you can give entries an expiry time, delete them when the source updates, or update cache and database together depending on how fresh the data must be.”
Code Example
async function getUser(id) {
const key = `user:${id}`;
const cached = await redis.get(key);
if (cached) return JSON.parse(cached);
const user = await db.findUser(id);
// Expire after 300s to bound staleness
await redis.set(key, JSON.stringify(user), 'EX', 300);
return user;
}
async function updateUser(id, data) {
await db.updateUser(id, data);
// Invalidate so the next read reloads fresh data
await redis.del(`user:${id}`);
}Follow-up Questions
- How does cache-aside differ from write-through caching?
- What is a cache stampede and how do you prevent it?
- How do Redis keyspace notifications help with invalidation?
- When would you choose write-behind despite the risk of data loss?
- How do eviction policies interact with invalidation?
MCQ Practice
1. What does cache invalidation prevent?
Invalidation removes or refreshes cached entries so clients stop reading values that no longer match the source of truth.
2. In the cache-aside pattern, what happens on a cache miss?
Cache-aside reads the cache first, and on a miss loads from the database and populates the cache for next time.
3. Which technique bounds how stale a cached value can become automatically?
A TTL makes an entry self-expire after a set time, capping the maximum staleness without manual action.
Flash Cards
What is cache invalidation? — Removing or refreshing cached data once the underlying source changes, so clients stop reading stale values.
How does cache-aside handle a miss? — It loads the value from the database and stores it back in the cache before returning it.
What does a TTL give you? — An automatic bound on staleness, since the entry self-expires after the set time.
Write-through vs write-behind? — Write-through updates cache and DB together for freshness; write-behind buffers DB writes for speed with loss risk.
What is a cache stampede? — Many keys expiring at once cause a flood of simultaneous database reloads; mitigate with jittered TTLs or locks.
Continue Learning
Related Interview Questions
What is the difference between write-through, write-behind, and cache-aside patterns?
medium
What is a cache stampede (thundering herd) and how do you prevent it in Redis?
hard
What are the trade-offs of using Redis for session storage?
medium
How does Redis client-side caching with CLIENT TRACKING work, and when is it worth it?
hard