NGINX stale-while-revalidate cluster

Lucas Rolff lucas at
Fri Jul 7 10:12:35 UTC 2017

Instead of doing round robin load balancing why not do a URI based load balancing? Then you ensure your cached file is only present on a single machine behind the load balancer.

Sure there will be moments where this is not the case – let's assume that a box goes down, and traffic will switch, but in that case I'd as a "post task" take the moment from when the machine went down, until it came online again, find all requests that expired in the meantime, and flush it to ensure the entry is updated on the machine that had been down in the meantime.

It will still require some work, but at least over time your "overhead" should be less.

From:  nginx <nginx-bounces at> on behalf of Joan Tomàs i Buliart <joan.tomas at>
Reply-To:  <nginx at>
Date:  Friday, 7 July 2017 at 11.52
To:  <nginx at>
Subject:  NGINX stale-while-revalidate cluster


 We are implementing an stale-while-revalidate webserver cluster with NGINX. 
 We are using the new proxy_cache_background_update to answer request as soon as possible while NGINX updates the content from the origin in the background. This solution works perfectly when the requests for the same object are served by the same NGINX server (when we have only one server or when we have a previous load balancer that classifies the requests). 
 In our scenario we have a round robin load balancer (ELB) and we need to scale the webservers layer. So, as a consequence, only the Nginx that receive the request updates the cache content while the others keep the old version. This means that, we can send old versions of content due to the content not being updated on all the webservers. The problem accentuates when we put a CDN in front of the webservers.
 We are thinking on developing something that once an Nginx instance updates its cache would let know all other instances to get a copy of the newest content. We are thinking about processing NGINX logs and, when it detects a MISS, EXPIRED or UPDATING cache status, it makes a HEAD request to the other NGINXs on the cluster to force the invalidation of this content.

 Do any of you have dealt with this problem or a similar one?

We have also tried the post_action but it is blocking the client request until it completes. It is not clear for us which would be the best approach. The options that we are considering are:
 - NGINX module
 - LUA script
 - External script that process syslog entries from NGINX
 What would be your recommendation?
 Many thanks in advance,
  Joan Tomàs-Buliart 

 Joan Tomàs-Buliart
 +34 931 785 950
 Discover our referral program!!
_______________________________________________ nginx mailing list nginx at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: olhgllimkponlhjm.gif
Type: image/gif
Size: 4180 bytes
Desc: not available
URL: <>

More information about the nginx mailing list