One more approach is to not change the contents of resources without also changing their name. One example would be the cache_key feature in Rails, where resources have a path based on some ID and their updated_at value. Whenever you modify a resource it automatically expires.
Sent from my iPhone On Sep 13, 2018, at 4:03 PM, Lucas Rolff <lu...@lucasrolff.com> wrote: >> How does one ensure cache consistency on all edges? > > I wouldn't - you can never really rely on anything being consistent cached, > there will always be stuff that doesn't follow the standards and thus can > give an inconsistent state for one or more users. > > What I'd do, would simply to be to purge the files whenever needed (and > possibly warm them up if you want them to be "hot" when visitors arrive), > sure the first 1-2 visitors in each location might have a bit slower request, > but that's about it. > > Alternatively you could just put a super low cache-control, when you're using > proxy_cache_background_update and proxy_cache_use_stale_updating, nginx will > ask the origin server if the file has changed - so if it haven't you'll > simply get a 304 from the origin (if the origin supports it) - so you'll do > more requests to the origin, but traffic will be minimal because it just > returns 304 not modified (plus some more headers). > > Best Regards, > Lucas Rolff > > > _______________________________________________ > nginx mailing list > nginx@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx _______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
