Cache Invalidation Strategies
Learn how to keep cached data fresh and consistent using TTLs, write-through, write-behind, and event-driven invalidation in Redis.
Cache Invalidation Strategies is a free Redis Caching & Messaging (Pub/Sub, Streams) lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Redis Caching & Messaging (Pub/Sub, Streams) learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Why Invalidation Matters
Caching speeds up reads, but a cache that serves stale data can be worse than no cache at all. Cache invalidation is the discipline of removing or refreshing entries when the underlying source of truth changes.
It is famously hard: there are only two hard things in computer science, and one of them is cache invalidation.
TTL-Based Expiry
The simplest strategy is time-to-live. You accept that data may be stale for at most N seconds.
SET key value EX 60expires after 60 secondsEXPIRE key 60sets a TTL on an existing keyTTL keyshows remaining seconds
SET user:42:profile "...json..." EX 60
TTL user:42:profile
EXPIRE user:42:profile 120Write-Through Caching
In write-through caching, every write goes to both the database and the cache in the same operation. Reads are always fresh, at the cost of slower writes.
The application is responsible for keeping the two in lockstep.
def save_user(user):
db.update(user)
redis.set('user:' + user.id, serialize(user))
return userWrite-Behind Caching
Write-behind (write-back) writes to the cache first and flushes to the database asynchronously. Writes are fast, but you risk data loss if Redis goes down before the flush.
Use a queue or stream to buffer pending writes.
redis.set('order:' + id, data)
redis.lpush('pending_writes', id)Explicit Deletion on Update
The cache-aside + delete pattern: on every update to the database, delete the cached key. The next read repopulates it.
This avoids serving stale data and is simpler than keeping the cache value in sync.
def update_product(p):
db.update(p)
redis.delete('product:' + p.id)Why Delete Beats Update
Deleting the key (instead of overwriting it) avoids a race condition: two concurrent updates could otherwise write values in the wrong order. With deletion, the next read always pulls the latest from the source of truth.
Versioned Keys
Instead of invalidating, bump a version number embedded in the key. Old keys expire naturally via TTL while new reads use the new key.
INCR config:version
GET config:version
SET config:v7:settings "..."Event-Driven Invalidation
Publish an invalidation event whenever data changes. Other application nodes subscribe and clear their local caches. This pairs Redis Pub/Sub with caching.
redis.publish('invalidate', 'user:42')
# subscribers:
redis.subscribe('invalidate')Tag-Based Invalidation
Group related keys under a tag set. When a tag becomes invalid, delete all member keys in one sweep.
SADD tag:user:42 product:1 product:2- On change:
SMEMBERS tag:user:42thenDELeach
SADD tag:user:42 cart:42 wishlist:42
SMEMBERS tag:user:42Avoiding Stampedes
When a hot key expires, many requests may hit the database at once (a cache stampede). Mitigate with a short lock, probabilistic early expiry, or serving slightly stale data while one worker refreshes.
SET lock:user:42 1 NX EX 5Choosing a Strategy
There is no single best approach:
- TTL for tolerable staleness
- Delete-on-write for correctness
- Event-driven for multi-node consistency
- Versioning for bulk config changes
Quick Check
Test your understanding of invalidation strategies.
Recap
You learned the major cache invalidation strategies: TTL expiry, write-through, write-behind, delete-on-write, versioned keys, event-driven, and tag-based invalidation, plus how to avoid cache stampedes. Pick the strategy that matches your tolerance for staleness and your consistency needs.
Frequently asked questions
Is the “Cache Invalidation Strategies” lesson free?
Yes — the full text of “Cache Invalidation Strategies” is free to read here on the web, and the Redis Caching & Messaging (Pub/Sub, Streams) course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Redis Caching & Messaging (Pub/Sub, Streams) course, upgrade to CoddyKit PRO.
What will I learn in “Cache Invalidation Strategies”?
Learn how to keep cached data fresh and consistent using TTLs, write-through, write-behind, and event-driven invalidation in Redis. You practise Redis Caching & Messaging (Pub/Sub, Streams) with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Redis Caching & Messaging (Pub/Sub, Streams)?
No prior experience is required. Redis Caching & Messaging (Pub/Sub, Streams) on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Cache Invalidation Strategies” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Redis Caching & Messaging (Pub/Sub, Streams) lesson?
Yes. Every Redis Caching & Messaging (Pub/Sub, Streams) lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Advanced Cache Patterns
- Session Management with Redis
- Rate Limiting and Anti-Patterns
- Cache Invalidation Strategies