Rolling Update

What is a rolling update?

A rolling update deploys a new version of a service by replacing instances incrementally — take down a few old instances, bring up new ones, verify they’re healthy, then repeat — while the remaining instances keep serving traffic throughout. There’s never a moment when the whole service is down, and you never need double the infrastructure. It’s the default deployment strategy in most orchestrators, most notably Kubernetes, where it’s how a Deployment rolls out a new container image out of the box.

How it compares to the alternatives

Rolling updates sit in the middle of the deployment-strategy spectrum, and knowing the tradeoffs clarifies when to use which. Versus blue-green: blue-green stands up a whole second environment and flips all traffic at once (instant rollback, but double the infrastructure during the switch); a rolling update needs no second environment (cheaper) but rollback is slower because you must roll backward through the instances, re-deploying the old version gradually. Versus canary: a canary deliberately routes a small, measured slice of traffic to the new version and gates promotion on metrics; a plain rolling update doesn’t do metric-gated traffic splitting — it just replaces instances on a schedule, so a bad version rolls out to everyone (a batch at a time) unless you’re watching. The key insight: a rolling update mixes old and new versions serving live traffic simultaneously during the rollout, which is its defining constraint. Kubernetes exposes knobs — maxUnavailable (how many instances can be down at once) and maxSurge (how many extra can be spun up) — to tune the speed/safety balance.

The constraints people underestimate

Because old and new run at the same time during the roll, two things must hold or the update breaks in subtle ways. First, the two versions must be mutually compatible — API contracts, message formats, and especially database schema changes must be backward-compatible, since v1 and v2 are both live against the same database mid-rollout (the same discipline blue-green and canary require). A migration that only v2 understands will break the v1 instances still running. Second, health checks (readiness probes) are load-bearing: the whole safety of a rolling update depends on the orchestrator correctly detecting that a new instance is actually ready before sending it traffic and before proceeding to replace the next batch — misconfigured or missing readiness checks let the system route traffic to instances that aren’t ready, or march the rollout forward over broken pods, turning “zero-downtime” into an outage. And note the slow-rollback caveat: if a bad version gets partway through, recovering means rolling forward-to-back again, which is why teams needing instant rollback lean toward blue-green. Rolling updates are the sensible default for stateless services with good health checks and backward-compatible changes; they’re a poor fit when you need instant all-or-nothing rollback or when versions genuinely can’t coexist.

What people get wrong

• Non-backward-compatible changes — old and new versions run together during the roll, so an incompatible schema or API change breaks the still-running old instances.
• Weak readiness probes: the strategy’s safety hinges on accurately detecting healthy new instances; bad health checks route traffic to unready pods or advance over broken ones.
• Expecting instant rollback — reverting means rolling gradually back to the old version; if you need immediate all-or-nothing rollback, blue-green fits better.

Primary source: Kubernetes: Performing a Rolling Update