If the data is in fact updated with clear hot/warm/cold sets, caching the cold sets should be extremely effective, the warm set moderately effective, and it may not even be worth caching the hot set at all, given the complexity proposed. Additionally, you should be able to offload the cold sets to persistent blob storage, away from your main database, and bulk load them as needed.
Finally, it can be faster and simpler to keep track of deltas to cold sets (late mutations that happen to "invalidate" the previously immutable data), by simply storing those updates in a separate table, loading the cold set data, and applying the delta corrections in code as an overlay when queried. Cron jobs can read those deltas, and fold them back into the cold set aggregations, making clean validated cold set data again.
Great article, BTW! There are entire database technologies and product dedicated to addressing these use cases, particularly as the data sets grow very large.
You can then invalidate any final cache key that uses one of the namespaces by incrementing the namespace key.
I haven't come across this technique mentioned elsewhere since, but it's very useful.
See the namespaces section in the now 404ing memcached FAQ https://web.archive.org/web/20090227062915/http://code.googl...
I guess nosql, edge caching and materialised views make it less applicable than it used to be (when inelastically scaling single/replicated SQL instances were the only game in town and taking load off them was vital).
Or is this technique now a first class feature of various cache client SDKs?
(Disclaimer: I used to work for them, but don’t anymore. It’s all available for free on GitHub though for anyone interested: https://github.com/readysettech/readyset)