Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Say I have two production webservers (web1 and web2) and a static asset origin server (origin1), and I want to deploy new code that references new css/js/images.

After updating web1 and putting it back on rotation, and right before I take web2 out of rotation, there'll be a brief window when the load balancer will send requests to both web1 with new code and web2 with old code:

  • web1 serves html that requests http://somecdn/images/foo.jpg?v=newhash
  • web2 serves html that requests http://somecdn/images/foo.jpg?v=oldhash

So in this brief window, there's a chance that somecdn might request for foo.jpg?v=oldhash, but actually gets served the new image that just got deployed to origin1. That's not good.

The obvious solution seems to be keeping both versions of the assets available:

  1. Version the releases like /2.1/images/foo.jpg and /2.2/images/foo.jpg, which defeats the purpose of cache-busting using the file hash, or
  2. Keep both versions by adding the hash to the file name, eg. keep both /images/foo.oldhash.jpg and /images/foo.newhash.jpg in the file system, which would leave a bunch of old files that needs pruning.
  3. Setup Varnish to keep older versions of css/js/images around (feels iffy).

Is there a better strategy, assuming that I can't disable the site completely while deploying?

(StackExchange uses this file hash approach for cache-busting…)

share|improve this question

You basically have to keep both versions available during the transition if you are going to overlap versions in production at all. Using the versions in the path component is actually what we do, since it so much simpler for the devs. Approach #2 requires a lot more scripting work as part of your build/deploy process - just one more thing to break. We use hardlinks in the underlying filesystems to keep same files from /V1/ and /V2/ from taking up too much space, and it also makes pruning very easy. Our origins can handle the increased hits during changeover (which happen at low-usage periods anyway).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.