We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningFoundation · Caching Strategies
Removing or updating stale cache entries when the underlying data changes. One of the two hard problems in computer science (along with naming things).
In short
Cache invalidation is the process of removing or updating cached copies of data once the original source changes, so readers stop getting stale results. It is the mechanism that keeps a fast cache consistent with the slower source of truth behind it.
In short
Cache invalidation is the process of removing or updating cached copies of data once the original source changes, so readers stop getting stale results. It is the mechanism that keeps a fast cache consistent with the slower source of truth behind it.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Cache Invalidation across a run of lessons, not one page. These 4 alone are about 107 minutes of step-by-step reading, every one with a quiz.
Careful per-row invalidation served more than twice the stale reads of doing nothing, because it raised the hit rate on the entries it cannot see.
The algorithm that makes adding or removing nodes cheap, an interview favorite and production essential.
A refresh-ahead cache reloads hot entries before their TTL ends, so readers stop waiting. A Redis lab measures the factor, the cost and stale-while-revalidate.
Resolving conflicts when offline changes sync with the server. CRDTs, last-write-wins, and merge strategies.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Cache Invalidationpay once,
yours for life
A cache is a fast copy of data that lives closer to whoever needs it: in RAM, on a CDN edge node, or in a service like Redis. The whole point is to avoid asking the slow source (a database, an API, a disk) every single time. The problem starts the moment the source changes. The cached copy is now wrong, and anyone reading it gets old data.
Cache invalidation is how you deal with that. You either delete the stale entry so the next read fetches fresh data, or you overwrite it with the new value. Done well, users never notice the cache exists. Done badly, you serve a deleted product, an old price, or a profile photo someone changed an hour ago.
The reason it has a reputation as one of the hard problems in computer science is timing. The source and the cache live in different places, updates take time to propagate, and many readers hit the cache at once. Deciding exactly when an entry is no longer valid, and making sure every copy of it learns that, is genuinely tricky at scale.
There are three common strategies, and most systems mix them. The first is time based expiry, or TTL. You tag each entry with a lifetime, say 60 seconds, and the cache automatically drops it when the clock runs out. It is simple and needs no coordination, but it accepts staleness for the length of the TTL.
The second is explicit invalidation on write. When your application updates a record, it also deletes or updates the matching cache key in the same code path. A common pattern is cache-aside: the app reads from the cache, falls back to the database on a miss, and on any write it deletes the key so the next read repopulates it. Deleting is usually safer than updating in place because it avoids a race where two writers leave a wrong value behind.
The third is event based invalidation. Instead of every writer knowing about every cache, a change emits an event, often through a log like Kafka or a database change stream, and subscribers purge the affected keys. CDNs work this way too: you call a purge API and the edge nodes drop the cached object. This decouples the writer from the caches but adds propagation delay measured in milliseconds to seconds.
Key design is the quiet part that decides whether any of this works. If a single piece of data is cached under five different keys, all five have to be invalidated or you will leak stale copies. Many bugs are not in the invalidation logic itself but in forgetting which keys depend on a given record.
The core trade-off is consistency versus cost. Aggressive invalidation keeps data fresh but means more cache misses, more load on the database, and more complexity in your write path. Loose invalidation, like a long TTL, keeps the database quiet but serves older data. You pick based on how much staleness the feature can tolerate. A bank balance needs immediate invalidation. A list of trending articles can be a minute stale and nobody cares.
Two failure modes are worth naming. A thundering herd happens when a popular key expires and thousands of requests miss the cache at the same instant and all slam the database. You guard against it with request coalescing or a short lock so only one request rebuilds the entry. Stale reads happen when invalidation is delayed or dropped, so you may add versioning or a write-through cache where the write updates cache and database together.
A practical rule: prefer deleting keys over mutating them, give every entry some TTL as a safety net even when you also invalidate explicitly, and never trust that an event-based purge always arrives. Belt and suspenders is cheaper than a stale-data incident.
Picture an e-commerce product page. The price and stock count are cached in Redis under a key like product:1234, with a 5 minute TTL. Reads are fast and the database barely sees traffic.
An admin drops the price. The update writes to PostgreSQL, then in the same request deletes product:1234 from Redis. The very next visitor misses the cache, reads the fresh price from PostgreSQL, and the cache repopulates with the new value. Total staleness window: effectively zero.
But the product also appears on a category listing cached under category:electronics, and in a search results cache. Those keys still hold the old price. So the write path also has to invalidate them, or accept that they will fix themselves when their own TTL expires. This is the everyday reality of invalidation: the hard part is not deleting one key, it is knowing every place a piece of data was copied to.
Redis
The most common application cache. Apps delete or overwrite keys on write, and use TTLs as a backstop against missed invalidations.
Cloudflare
CDN caching with a purge API and cache tags so origins can invalidate edge copies of pages and assets on demand.
Its Memcache layer uses leases and a cache invalidation pipeline to keep thousands of cache servers in sync with the database after writes.
Varnish
HTTP reverse-proxy cache where stale content is purged or banned by URL pattern, widely used in front of news and media sites.
Because the cache and the source of truth live in different places and update at different times, with many readers and writers hitting them at once. Knowing exactly when an entry is stale, and making sure every copy of it across servers or edge nodes learns that at roughly the same time, is a distributed timing problem with lots of edge cases.
Usually delete it. Deleting lets the next read repopulate from the source, which sidesteps the race where two concurrent writers leave a wrong value in place. Updating in place is only safe when you fully control ordering, such as in a write-through cache that updates the cache and database atomically.
A TTL expires an entry automatically after a fixed time and needs no coordination, but it tolerates staleness for that whole window. Explicit invalidation removes the entry the instant the data changes, so it is fresher but requires the write path to know exactly which keys to clear. Most systems use both: explicit invalidation for correctness and a TTL as a safety net.
It happens when a popular cache key expires and many requests miss simultaneously, all hammering the database to rebuild the same value. You avoid it with request coalescing or a short lock so only one request recomputes the entry while the rest wait, and sometimes by refreshing hot keys slightly before they expire.
No. Events can be dropped, purges can lag, and you can forget that data was cached under more than one key. Treat invalidation as best effort and add safety nets: give entries a TTL, version your keys when data changes shape, and design so a brief stale read is tolerable rather than catastrophic.
Caching
Storing frequently accessed data in a faster storage layer so you don't have to fetch it from the original (slower) source every time.
TTL
Time To Live: how long a cached entry, DNS record, or packet is valid before it expires and must be refreshed or discarded.
Write-Through Cache
A caching pattern where every write goes to both the cache and the database simultaneously. Ensures consistency but adds write latency.
Cache Stampede
When many requests hit the database simultaneously because a popular cache entry expired. Solved with locking, probabilistic early expiration, or request coalescing.
CDN
A network of servers distributed globally that caches content close to users. Netflix uses CDNs to stream video from servers near you, not from one central location.
Cache Eviction
The process of removing entries from a cache when it's full. Common policies: LRU (least recently used), LFU (least frequently used), FIFO (first in, first out).
This page explains the idea. The "Cache Invalidation" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Cache Invalidation lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Cache Invalidation in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
