cache invalidation

2008-01-23 @ 23:31#

found this today when trolling for things related to exyus. it covers dealing with cache invalidation. something i spent quite a bit of time with over the last couple months.

here's the deal. most of the stff i've read about caching deals with *data* caching. caching data objects, data collections, etc. this is fine. and there are some decent scaffolding for handling this. but that's not really where i decided to go. instead, i focused on the caching patterns from HTTP web caching. in other words, i focused on caching at the web server level, not the data level.

why? because that's where it's really needed. i figure that once the page is built - it's the *page* you want to cache. sure, the underlying data can be cached and that's fine. especially if you plan on re-using that underlying data multiple times to build *different* pages. but that's just *part* of the deal.

instead, even if you only need the underlying data *once* you still need to cache the final page. and that's why i think HTTP caching is the way to go. another reason to focus on HTTP caching is to enforce the power of unique URLs. if the URL is the cache key, then it allows you to use a list of URLs as the list for cache dependencies and cache invalidation. even better, if you use the HTTP caching pattern and you have cache keys that are unique URLs, then you can also use HTTP commands to invalidate that cache! just make HEAD calls to the HTTP server with the cache-control:no-cache header and !boom! you're invalidating the cache *and* updating it at the same time.

of course, once this is working, it's not such a big deal with *add* data caching. but that's another story.

code