We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · DevOps & CI/CD
Gradually replacing old instances with new ones, a few at a time. No downtime, but both versions run simultaneously during the rollout.
In short
A rolling deployment updates an application by replacing old instances with new ones a few at a time, instead of all at once. Each batch of servers is upgraded and health-checked before the next batch starts, so the service stays available throughout with no downtime, though both the old and new versions run side by side during the rollout.
In short
A rolling deployment updates an application by replacing old instances with new ones a few at a time, instead of all at once. Each batch of servers is upgraded and health-checked before the next batch starts, so the service stays available throughout with no downtime, though both the old and new versions run side by side during the rollout.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Rolling Deployment across a run of lessons, not one page. These 4 alone are about 74 minutes of step-by-step reading, every one with a quiz.
Replacing application instances one at a time, keeping the service available throughout the update.
Update instances gradually, replace old with new one at a time to minimize risk.
Routing a small percentage of production traffic to the new version and monitoring before full rollout.
Recording, measuring, and learning from every minute your service is unavailable.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Rolling Deploymentpay once,
yours for life
When you ship a new version of an app, you have to get the new code onto the servers that are serving live traffic. The blunt way is to take everything down, swap the code, and bring it back up. That causes downtime. A rolling deployment avoids that by updating the fleet in small steps.
Say you run 10 identical instances behind a load balancer. A rolling deployment might take 2 instances out of rotation, replace them with the new version, wait for them to pass health checks, put them back, then move on to the next 2. After five waves, all 10 are running the new version and the service never went fully dark.
The batch size is the key knob. It is often expressed as maxSurge (how many extra instances you are allowed to spin up above the desired count) and maxUnavailable (how many you are allowed to take down at once). These two numbers control how fast the rollout moves and how much capacity you keep online while it happens.
The orchestrator keeps a count of how many instances should be running and which version they should be. To roll out a change, it brings up new-version instances, waits for each to report healthy, then terminates an equal number of old-version instances. It repeats until the whole set matches the new version.
Health checks are what make this safe. A new instance does not receive traffic until a readiness probe confirms it is actually serving requests, not just started. If a batch fails its checks, a good system halts the rollout and leaves the rest of the fleet on the old version, so a bad build degrades capacity instead of taking the site down.
Because old and new run at the same time, both versions must speak to the same database and the same clients. This is why backward-compatible changes matter. If version 2 renames a database column that version 1 still reads, you break the instances that have not been upgraded yet. The usual fix is to deploy schema changes in expand-then-contract steps so both versions stay happy during the overlap.
Rolling deployments are the default in most container platforms because they need no extra infrastructure. You upgrade in place using the capacity you already have, which makes them cheaper than blue-green deployment, where you stand up a full second copy of the fleet.
The cost is that rollback is slow. If version 2 turns out to be broken, you cannot flip a switch back to version 1 the way blue-green lets you. You have to run the whole process again in reverse, batch by batch, which can take minutes. During that window some users hit the bad version. Canary deployments address this by sending a tiny slice of traffic to the new version first, but a plain rolling update does not give you that fine-grained control.
Use rolling deployments for stateless services where any instance can handle any request and the new version is backward compatible. Avoid them, or pair them with stronger safeguards, when a release contains breaking changes, when you cannot tolerate two versions running together, or when you need instant rollback for a high-risk change.
Kubernetes uses rolling updates by default for Deployments. If you change the container image in a Deployment running 10 replicas, the controller creates a new ReplicaSet for the new image and scales it up while scaling the old one down, respecting maxSurge and maxUnavailable. With the defaults of 25 percent each, it adds up to 3 new pods and removes up to 3 old pods at a time.
Each new pod must pass its readiness probe before Kubernetes counts it as available and routes Service traffic to it. If pods crash-loop or never become ready, the rollout stalls and you can run kubectl rollout undo to revert to the previous ReplicaSet, which itself happens as another rolling operation.
The same pattern shows up outside Kubernetes. AWS rolling deployments in Elastic Beanstalk and CodeDeploy upgrade EC2 instances in configurable batches, and Auto Scaling group instance refresh replaces instances a percentage at a time while keeping a minimum healthy count online.
Kubernetes
Rolling update is the default strategy for Deployments, controlled by maxSurge and maxUnavailable with readiness-probe gating between batches.
AWS Elastic Beanstalk and CodeDeploy
Both offer rolling and rolling-with-additional-batch deployment policies that upgrade EC2 instances in configurable batches.
Nginx and HAProxy fleets
Operators drain connections from one node at a time, upgrade it, and return it to the pool behind the load balancer for zero-downtime releases.
HashiCorp Nomad
Job updates use a rolling update stanza with max_parallel and health checks to replace task allocations incrementally.
A rolling deployment upgrades your existing instances in place, a few at a time, so you only ever run one fleet. Blue-green stands up a complete second fleet on the new version and switches all traffic at once when it is ready. Rolling is cheaper and needs no extra capacity, but rollback is slow. Blue-green doubles your infrastructure briefly but gives near-instant rollback by flipping traffic back.
No, that is the point of it. Because only a small batch of instances is offline at any moment and the rest keep serving traffic behind a load balancer, users do not see an outage. The catch is that two versions run at the same time during the rollout, so the new version must be backward compatible with the old one and with the shared database.
You run the deployment process again targeting the previous version, which replaces the new instances batch by batch. In Kubernetes this is kubectl rollout undo, which redeploys the prior ReplicaSet. Because rollback is itself a rolling operation it takes time, which is the main downside compared to blue-green. Good readiness probes help by halting the rollout before a bad version reaches the whole fleet.
They control how aggressive the rollout is. maxSurge is how many extra instances you may run above the desired count during the update, which lets you add new instances before removing old ones. maxUnavailable is how many instances are allowed to be down at once. Setting maxUnavailable to 0 and maxSurge above 0 keeps full capacity throughout but uses more resources during the rollout.
Because old and new code run against the same database at the same time, a schema change that one version expects but the other cannot handle will break the instances on the wrong version. The safe approach is expand-then-contract: first add new columns or tables that both versions tolerate, deploy the new code, then remove the old schema in a later release once no instance depends on it.
The industry examples in “The next question”:
Blue-Green Deployment
A deployment strategy using two identical environments. Traffic switches from blue (current) to green (new) instantly, with easy rollback.
Canary Deployment
Rolling out a new version to a small percentage of users first, then gradually increasing. Like sending a canary into a coal mine to test for danger.
Kubernetes Deployment
A K8s resource that manages rolling updates and rollbacks for a set of pods. You declare the desired state and K8s converges to it.
CI/CD
Continuous Integration and Continuous Deployment: automating the process of testing and deploying code. Push code, tests run, and it ships to production automatically.
GitOps
Using Git as the single source of truth for infrastructure and application configuration. Changes are made via pull requests and automatically reconciled by tools like ArgoCD or Flux.
Immutable Infrastructure
Servers are never modified after deployment. To update, you build a new image and replace the old instance entirely. Eliminates configuration drift.
This page explains the idea. The "Rolling Deployment" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Rolling Deployment lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Rolling Deployment in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
