I’m designing an abstraction over ASP.Net’s built in caching to make it not so horrible to use. One design decision I’m having to look at is if I should restrict people to using just one cache policy on each item.
For example, say you’re caching the HTML generated by your blog post or some such. Would you ever want to cache it sometimes for 30 minutes and sometimes for 2 hours? Note: this isn’t cache invalidation.
These are the policies available:
- Priority
- Absolute expiration
- Sliding expiration (where each access bumps the expiration by this much)
Are there any use cases where someone would want to add an item to the cache with one set of policies and in another portion of the web application use a different set of policies when it gets added(but of course, if it already exists keep with the old policy)? Are there any real world uses to allowing this?
This one time, at band camp…
I’ve build a similar cache mechanism to what you’re describing to counter-act (predictable) traffic spikes. It was a hack, and the only reason we went for it was that (at the time) we couldn’t afford to upgrade our infrastructure to cope with the intense spikes and because it was quite easy to predict exactly what resources would be in demand during those spikes and when the spikes would happen (niche market + tons of existing traffic data).
The inspiration from the hack was a similar hack I’ve seen used in a (then) popular CMS platform to counter-act the Slashdot effect. The system would react to tons of visitors in a short time by automatically increasing TTLs (If I remember correctly, the increase was logarithmic).
In any case, conditional/adaptive caching is not uncommon, it’s common enough that we have quite a few awesome algorithms for it. The question is, do you really need it? If not, well, I’m sure you know what they say about premature optimization…
1