Rolling Deployment: Update Servers Without Downtime
A rolling deployment upgrades servers one by one, like swapping train cars while the train moves. A load balancer directs users to active servers, keeping the app online. The main footgun is incompatibility between old and new code running at the same time.
Why it exists
The traditional "stop-the-world" update process causes significant application downtime. If an error occurs during the update, rolling back is also a lengthy, disruptive process. Rolling deployments were created to update applications with zero or minimal downtime, providing a safer, more continuous user experience.
The mental model
Imagine a pit crew changing the tires on a race car one at a time while it's still slowly rolling around the track. The car never fully stops. A rolling deployment does this for servers in a cluster: it takes one server out of rotation, updates it, and puts it back, all while the application as a whole continues serving users.
How it works
In a server cluster managed by a load balancer, a rolling deployment updates a small subset of servers at a time. This subset is called the "window size". The load balancer is configured to stop sending traffic to the server(s) in the current window. Once idle, the server receives the new software version and is tested. After passing tests, it's returned to the pool of active servers. This process repeats for the next window of servers until the entire cluster is running the new version.
When to use it
Use a rolling deployment when your primary goal is to avoid application downtime and you have an application running on multiple servers. It's a common, resource-efficient strategy for web services and APIs where continuous availability is critical but you don't have the resources to spin up a full parallel environment like in a blue/green deployment.
When not to use it
Avoid rolling deployments if your application changes are not backward compatible. If the new code cannot work with the old database schema (or vice versa), the deployment will fail or corrupt data as mixed versions run simultaneously. Also, if user sessions cannot be reliably managed across nodes with different versions (e.g., via session persistence), it can lead to a broken user experience.
One canonical example
A web application runs on three servers behind a load balancer. To deploy a new version, you start a rolling deployment with a window size of one. The load balancer drains connections from Server 1. Once idle, Server 1 is updated and tested. After it passes, it's put back into service. The process then repeats for Server 2, and finally for Server 3. At no point were all servers offline, so users experienced zero downtime.
Interview question
What is the primary risk associated with using a rolling deployment strategy?
- a.Data corruption or application failure if old and new code versions are not backward compatible.Correct
- b.The entire application becoming unavailable if a single server fails during the update.
- c.High resource consumption due to the need for parallel environments.
- d.The inability to roll back to the previous version after a failed deployment.
Why? this is the answer
The card explicitly states that the "main footgun is incompatibility between old and new code running at the same time" and warns against using rolling deployments if changes are not backward compatible, as this can lead to "data corruption or application failure." Option D is less accurate because while rollback is always a consideration, the card highlights incompatibility as the primary risk specific to the concurrent running of old and new versions.
Just read this? Test yourself on what you have been reading.
Read the original → techtarget.com
- #deployment
- #ci/cd
- #devops
- #availability
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on deployment — each one lists the topics its interview covers.
See open roles