On this page
Why cache invalidation is hard
Write policies: where staleness comes from
Write-through cache
Write-around cache
Write-back cache (or lazy-write)
Write-behind cache
Cache invalidation methods
Purge
Refresh
Ban
Time-to-live (TTL) expiration
Stale-while-revalidate
How to invalidate a cache in practice
Choosing a method
Frequently asked questions
Related reading
Related questions
Cache Invalidation: Methods, Strategies, and Trade-offs
On This Page
Why cache invalidation is hard
Write policies: where staleness comes from
Write-through cache
Write-around cache
Write-back cache (or lazy-write)
Write-behind cache
Cache invalidation methods
Purge
Refresh
Ban
Time-to-live (TTL) expiration
Stale-while-revalidate
How to invalidate a cache in practice
Choosing a method
Frequently asked questions
Related reading
Related questions
Cache invalidation is the process of removing or updating outdated data in a cache, so that only current data is served. A cache stores frequently used data in fast memory, which avoids a trip to slower storage. When the original data changes, the cached copy has to be removed or updated, or users see stale results.
Why cache invalidation is hard
The difficulty is not the removing. It is knowing when to remove.
The cache has no way to learn that the source data changed. Something has to tell it, and every option for telling it costs something.
Notify on every write and you add work to the write path. Wait for a timer and you serve stale data until the timer runs out.
There is also a timing problem. Between the moment the database changes and the moment the cache is updated, the two disagree. Under load, many requests can arrive in that window.
The rest of this article covers where staleness comes from, the five methods used to remove it, and how to choose.
Write policies: where staleness comes from
A write policy decides where a write goes and when. It is not invalidation itself, but it sets how far apart the cache and the database can drift.
Write-through cache
Data is written into the cache and the database at the same time. Retrieval is fast, and the cache and storage always agree, so nothing is lost in a crash or power failure. The cost is write latency, because every write has to complete twice before the client is told it succeeded.
Example: An online store updates product stock in real time. When stock changes, the cache is updated to match the new count.
Write-around cache
Similar to write-through cache, but data goes straight to permanent storage and skips the cache. This keeps the cache from filling with writes nobody reads again. The cost is that a read of recently written data is a cache miss, so it comes from slower storage.
Example: An application updates user profile details that are rarely read. It writes to the data store directly and leaves the cache alone.
Write-back cache (or lazy-write)
Data is written to the cache alone, and the client is told immediately that the write succeeded. The write to permanent storage happens later, for example when the system needs free space. This gives low latency and high throughput for write-heavy applications. The risk is data loss in a crash, because the only copy is in the cache.
Example: In a collaborative document editor, edits are saved to the cache first, which keeps typing responsive. Once enough changes build up, the application writes them back to the data store.
Write-behind cache
Almost the same as write-back. Data is written to the cache and acknowledged at once, and the write to permanent storage is deferred. The difference is timing. Write-back flushes when the cache needs space or an event triggers it, while write-behind flushes on a schedule.
Example: A document editor saves changes to the cache as the user types, then writes them to the data store at fixed intervals.
Cache invalidation methods
These are the five methods used to invalidate a cache.
Purge
Purge removes cached content for a specific object or URL. It is used when content has changed and the cached copy is no longer valid. The cached copy is removed at once, and the next request goes to the origin server.
Example: A news site purges one article from its cache after a significant correction, so readers get the corrected version.
Refresh
Refresh fetches the content from the origin server even though a cached copy exists, then updates the cache with it. Unlike a purge, it does not remove the cached copy first. It replaces it.
Example: An online store refreshes a product page cache when a sale starts, so the new price shows.
Ban
Ban invalidates cached content that matches a rule, such as a URL pattern or a header. Everything matching is removed at once, and later requests go to the origin server.
Example: A content system bans every cached page carrying one tag when that tag changes.
Time-to-live (TTL) expiration
Each cached item gets a time-to-live, which is how long it may be served before it counts as stale. On a request, the cache checks the TTL. If it has not expired, the cached copy is served. If it has, the cache fetches a fresh copy and stores it.
Example: A weather site sets a one-hour TTL on forecast data, which keeps it reasonably current without hammering the origin server.
Stale-while-revalidate
Used in browsers and CDNs. The cached copy is served immediately, even if stale, while a background request fetches the current version and updates the cache. The reader never waits, and the next reader gets fresh data.
Example: A streaming service serves video thumbnails this way, so browsing stays fast while thumbnails update in the background.
How to invalidate a cache in practice
Most systems combine a few of these rather than picking one.
By key. Delete the exact entry when the record behind it changes. Precise, and it needs your write path to know which keys are affected.
By pattern or tag. Group related entries under a tag, then invalidate the tag. Useful when one change affects many cached pages.
By time. Set a TTL and let entries expire. The least work and the least precise.
On write. Update the cache as part of the write itself, which is what write-through does.
A practical default is a short TTL plus targeted deletes on the writes you know about. The TTL bounds how wrong you can be, and the deletes handle the changes that matter.
Choosing a method
| Method | Removes data | Best when |
|---|---|---|
| Purge | One object, immediately | A specific item changed and staleness is not acceptable |
| Refresh | Replaces in place | You want no gap where the item is missing |
| Ban | Everything matching a rule | One change affects many cached items |
| TTL | On expiry | Data ages predictably and small staleness is fine |
| Stale-while-revalidate | In the background | Speed matters more than being perfectly current |
The trade-off is the same every time. More precise invalidation means more work on the write path. Less precise means serving stale data for longer.
Frequently asked questions
What is cache invalidation? It is removing or updating cached data after the original changes, so users are not served stale results. It can happen on a timer, on a write, or through an explicit request to remove an entry.
Why is cache invalidation considered hard? Because the cache cannot know that the source changed. Something has to tell it, and there is always a window where the cache and the database disagree. Making that window smaller costs work on every write.
What is the difference between cache invalidation and cache eviction? Invalidation removes data because it is out of date. Eviction removes data because the cache is full and needs room. See cache eviction strategies for how items are chosen.
What is the difference between purge and refresh? Purge removes the cached copy, so the next request goes to the origin. Refresh fetches the new version and replaces the cached copy in place, leaving no gap.
Is a TTL enough on its own? For data that ages predictably, yes. For anything where a stale read causes a real problem, such as prices or permissions, pair a short TTL with a targeted delete on write.
Related reading
- Caching in system design interviews
- Cache eviction strategies
- Redis cache
- Eventual consistency
- Content delivery networks in system design
Related questions
Caching questions come up in almost every system design round, and the follow-up is nearly always about staleness. Grokking the System Design Interview works through where caches belong in 15 designs, and Volume II goes deeper on consistency.
What our users say
Brandon Lyons
The famous "grokking the system design interview course" on http://designgurus.io is amazing. I used this for my MSFT interviews and I was told I nailed it.
Arijeet
Just completed the “Grokking the system design interview”. It's amazing and super informative. Have come across very few courses that are as good as this!
AHMET HANIF
Whoever put this together, you folks are life savers. Thank you :)
Access to 50+ courses
New content added monthly
Certificate of completion
$31.08
/month
Billed Annually
Recommended Course
Grokking the Object Oriented Design Interview
60,422+ students
4.2
Learn how to prepare for object oriented design interviews and practice common object oriented design interview questions. Master low level design interview.
View CourseRead More
