Rolling Deployments

Have you ever tried to change the tires on a car while it's still driving down the highway? Probably not, because that sounds like a terrible idea. But in the world of software engineering, we often have to do exactly that: upgrade our systems without causing any downtime for our users.

Enter the Rolling Deployment.

In this article, we'll dive into what rolling deployments are, why they are a staple in modern continuous delivery, and how massive companies like Amazon and Netflix use them to keep the lights on while shipping new code.

The "Changing Tires" Analogy

Think of a rolling deployment like replacing a fleet of old delivery trucks with shiny new ones. You don't take all your old trucks off the road at once to bring in the new ones. That would mean halting all deliveries.

Instead, you replace them one by one (or in small batches).

1. You take one old truck out of service.
2. You bring one new truck online.
3. Once the new truck is running smoothly, you move to the next old truck.
4. You repeat this until the entire fleet is replaced.

Your customers never notice a drop in service because there's always a truck available to deliver their packages.

What is a Rolling Deployment?

In a rolling deployment, an application is updated to a new version by gradually replacing current instances (servers, containers, or pods) with new ones. It completely avoids the dreaded "maintenance window" where you have to take the whole system offline for an hour at 2 AM.

Instead of a big-bang release where you switch everything at once, a rolling deployment updates a small percentage of the fleet at a time. If the new version crashes or behaves badly, only a small subset of users is affected, and the deployment can be halted or rolled back.

The Mechanics

Let's say you have an application running on 10 servers behind a Load Balancer.

1. Step 1: The Load Balancer stops routing traffic to Server 1.
2. Step 2: Server 1 is updated to Version 2 (V2).
3. Step 3: Server 1 runs health checks. If it passes, the Load Balancer starts sending it traffic again.
4. Step 4: The process moves to Server 2, and so on, until all 10 servers are running V2.

This process ensures that at any given time, at least 9 servers are actively handling user requests.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

Before: All 3 servers run V1. The load balancer distributes traffic evenly across all of them.

1 / 10.5×1×2×3×Playground

Before: all servers on V1. | During: one server drains and updates while the others handle all traffic. | After: all servers on V2.

Real-World Examples

Amazon's Continuous Deployment Engine

Amazon is famous for deploying code to production every few seconds. They rely heavily on rolling deployments across their massive fleet of EC2 instances. By using tools like AWS CodeDeploy, they configure their deployments to update instances in batches—say, 10% of the fleet at a time. If the error rate spikes, the deployment is automatically canceled.

Kubernetes and Pods

If you use Kubernetes, rolling deployments are practically built-in. By default, when you update a Kubernetes Deployment, it performs a rolling update. It spins up a new pod with the new version, waits for it to become "ready," and then kills an old pod. It's seamless, and it's why Kubernetes has become the defacto standard for orchestrating containers.

The Pros and Cons

Like any system design pattern, rolling deployments come with trade-offs.

The Good Stuff

• Zero Downtime: Users don't experience an outage during the update.
• Gradual Risk: If the new version is buggy, it doesn't take down the entire system at once. You can catch the issue early.
• No Extra Hardware Needed: Unlike Blue-Green deployments (which we'll cover in another article), you don't need to spin up a completely separate, duplicate environment. You reuse your existing capacity.

The Catch

• Slow Rollouts: If you have 1,000 servers and update them one by one, the deployment could take hours.
• Version Compatibility: During the rollout, some users will hit V1 and some will hit V2. This means your database schema, APIs, and front-end code must be backward and forward compatible.
• Tricky Rollbacks: If things go wrong halfway through, you have to do a "reverse rolling deployment" to put the old version back, which takes time.

[!TIP] Backward Compatibility is King! When doing rolling deployments, always ensure that your database changes are made in a way that doesn't break the old code. A common strategy is the "expand and contract" pattern for database migrations.

When Should You Use It?

Rolling deployments are the bread and butter of modern web applications. They are best suited for:

• Stateless microservices where spinning instances up and down is cheap and fast.
• Systems that cannot tolerate any downtime (e-commerce, streaming, banking).
• Teams that have automated health checks and good monitoring in place to catch errors during the rollout.

Summary

Rolling deployments let you upgrade your software fleet piece by piece without bringing down the system. The requirement is that old and new versions can run side by side: the same API contracts, the same database schema. Get that right and you get zero-downtime deployments as a default.