Cache Invalidation
Cache invalidation is a process in a computer system whereby entries in a cache are replaced or removed.
It can be done explicitly, as part of a cache coherence protocol. In such a case, a processor changes a memory location and then invalidates the cached values of that memory location across the rest of the computer system.
Approaches
Purge
Removes content from caching proxy immediately. When the client requests the data again, it is fetched from the application and stored in the caching proxy. This method removes all variants of the cached content.
Refresh
Fetches requested content from the application, even if cached content is available. The content previously stored in the cache is replaced with a new version from the application. This method affects only one variant of the cached content.
Ban
Unlike purge, ban does not remove the content from the cache immediately. Instead, a reference to the content is added to a blacklist (or ban list). Every client request is checked against this blacklist. If the request happens to match blacklisted content, fresh content is fetched from the application, stored in the proxy server and returned to the client.
Bans cannot remove content from cache immediately because that would require going through all cached content, which could take a long time and reduce performance of the cache.
The ban solution may seem cumbersome, but offers more powerful cache invalidation, such as selecting content to be banned by regular expressions. This opens the way for powerful invalidation schemes, such as tagging cache entries.
Alternatives
There are a few alternatives to cache invalidation that still deliver updated content to the client.
Short TTL
One alternative is to expire the cached content quickly by reducing the time-to-live (TTL) to a very low value.
However, short TTLs cause a higher load on the application because content must be fetched from it more often. Moreover, reduced TTL does not guarantee that clients will have fresh content, especially if the content changes very rapidly as a result of client interactions with the application.
Validate Cached Content
Another alternative is to validate the cached content at each request.
A third option is to not cache volatile content requested by the client. These alternatives can cause issues, as they create high load on the application due to more frequent requests for information.
One Implementation Architecture
Reference
- https://en.wikipedia.org/wiki/Cache_invalidation
- https://cloud.google.com/cdn/docs/cache-invalidation-overview
- https://foshttpcache.readthedocs.io/en/stable/invalidation-introduction.html
- https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=404087915&idx=1&sn=075664193f334874a3fc87fd4f712ebc&scene=21#wechat_redirect
- https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final170_update.pdf