Stackbook Logo
deploymentestablished · low operational burden

Rolling Update

Also known as: rolling-deployment, rolling-upgrade

Intent

Replace instances of a service gradually in small batches so capacity and availability are maintained throughout the release.

Problem

Stopping every instance and starting new ones causes downtime, while duplicating the whole fleet for a switchover is expensive. A release process is needed that keeps the service up using roughly the capacity already provisioned.

Forces

  • •Service must remain available during the release
  • •Spare capacity is limited
  • •New instances must be proven healthy before old ones go
  • •Old and new versions coexist temporarily

Solution

Overview

A rolling update swaps instances a few at a time. It is the default for Kubernetes Deployments, autoscaling group instance refresh and many PaaS products because it needs no extra environment and no custom routing.

How it works

Two knobs control the pace: how many extra instances may be created (surge) and how many may be missing (unavailable). With ten replicas, surge 2 and unavailable 0, the controller adds two new pods, waits for readiness, removes two old ones, and repeats.

v1 v1 v1 v1 v1 v1 v1 v1 v1 v1
v1 v1 v1 v1 v1 v1 v1 v1 v2 v2   (surge)
v1 v1 v1 v1 v1 v1 v2 v2 v2 v2
...
v2 v2 v2 v2 v2 v2 v2 v2 v2 v2

strategy:
  rollingUpdate:
    maxSurge: 2
    maxUnavailable: 0

Each old instance gets a termination signal, stops accepting new requests and finishes in-flight work before exit.

Pitfalls

  • Readiness probes that only check the process is alive, not that dependencies and caches are warm.
  • Schema changes that the old version cannot read. Use expand-contract migrations.
  • Terminating too fast. Set a grace period longer than your slowest request and handle SIGTERM.
  • Not setting a progress deadline, so a stuck rollout is never flagged.
  • Assuming rollback is instant; it is a second rolling pass.
  • Long-lived connections such as websockets that pin clients to old instances.

Key takeaways

  • Replace in small batches while keeping capacity.
  • Readiness checks and graceful shutdown are what make it safe.
  • Plan for two versions serving at once.
  • Rollback takes as long as rollout.
  • Choose canary or blue-green when you need traffic control or instant revert.

✓ When to Use

  • •Stateless services behind a load balancer
  • •Default deployment strategy on orchestrators like Kubernetes
  • •When doubling capacity for blue-green is too costly

✗ When Not to Use

  • •Changes incompatible between consecutive versions
  • •Need for instant all-at-once cutover or instant rollback
  • •Strict need to test the full new fleet before any user traffic

Pros

  • +No downtime with modest extra capacity
  • +Simple and built into most platforms
  • +Natural early failure detection on first batches

Cons

  • −Mixed-version window requires compatibility
  • −Rollback is another slow rolling pass
  • −Gives limited traffic control compared with canary

Cost Profile

Infrastructure

Low - small surge capacity

Operational

Low - platform native

Cognitive

Low - well understood

Failure Modes

  • Weak readiness probe lets broken pods receive traffic

  • Rollout stalls halfway leaving a long mixed-version state

  • Connections are cut because draining is too short

Real-World Examples

Alternatives

  • blue-green-deployment
  • canary-deployment

Related Patterns

  • deployment-strategies
  • kubernetes-patterns
  • expand-contract-migration

Competency Domains

reliability ops