Ask HN: What is the most clever web caching strategy your company is using?

It seems nowadays everyone is using static assets which are cached forever by the CDN, and changes are pushed to the users by adding some sort of content hash into the filename. You benefit from the browser keeping all files in the cache forever, and yet you can deploy changes very easily by simply using a different filename for the updated assets.

Yesterday I became aware of a different technique, for which I couldn't find extensive documentation yet: We're building a social network type website and I found out that you can (and should) mix Etag-based caching and the traditional "Cache-Policy: private, max-age=XXX, must-revalidate" on the same route, depending on which user is requesting the data.

This approach solves the issue that you want to cache all your api route responses at the client, but if the user wants to change some of their own data (which can be changed by the user but is also fetched through the same API) you can reply to the user's own objects with the dynamic Etag instead of the forever-lasting "Cache-Policy".

It is a pretty simple concept to address caching not only on a per-route, but also on a per-user-per-route level.

In the end, it left me wondering what other things in terms of web caching I have been overlooking in the past few years. I'd appreciate if you could share your stories.