I have multiple frontend servers churning out the HTML pages , behind a load balancer.

Just wondering what is the best practice to update the frontend app while users are surfing the site.

The objectives:

  1. ensure each user see either the new or old version, but not flip between both.
  2. ensure load is still evenly distributed amongst servers that are not being updated.
  3. no disruption to service.

My thoughts:

  1. Divide the servers into groups.
  2. Take out a group from load balancing and wait for it to finish off current requests.
  3. Update the app and OS, etc.
  4. put the group back to load balancing.
  5. Pick another group and repeat steps 2-5.

While in process, some servers will have the new version, so to ensure users do not flip between the old and new ones, do I enable sticky session?

1 Answer 1


What you have above seems like a reasonable update procedure, however you can also use persistence or a sticky session so that when a user goes to a web server, they will be routed to the same web server for the life of their browser session (or for the next hour, or whatever you decide to configure). This also allows for some A/B testing if you need to get user feedback on a new feature or just allow for the possibility of a bug (just pull server group B from the pool if an issue is discovered during A/B testing with that group).

There are some concerns you should be aware of with sticky sessions: Eg, source address persistence can be problematic if you have a thousand users behind a firewall - then you have a huge group that always goes to a single web node. Maybe you really don't want a cookie to do persistence, etc.

But, there really is no agreed "best practice" on this - the best practice is going to the the one that meets your business need in this case. You should just collect all of your options and choose the workflow that best meets your needs.

  • It just depends on the architecture of your app. You don't need sticky sessions if the web servers are stateless or of the state is shared amongst the cluster - eg, is there a login? Do all web servers know all of the login tokens? For users with cookies disabled, you can often have fallback persistence - eg, use source address if cookies can't be used. I've also seen persistence based on ssl session ID. Commented Jun 29, 2018 at 16:48
  • ...if you choose to update them that way, yes. But you can also deactivate group A, update it, Deactivate Group B and Active Group A simultaniously, Update group B and then reactivate group B, in which case you wouldn't need sticky sessions. Commented Jun 30, 2018 at 16:40
  • Then you will probably want sticky sessions. Commented Jun 30, 2018 at 18:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.