Rolling Deployment

A rolling deployment replaces instances of the previous version of an application with instances of the new version, one instance at a time, until all instances are running the new version.

Intent

Rolling deployment is the lowest-cost release strategy: it replaces application instances one by one (or in small batches), with no requirement for a duplicate environment (unlike Blue/Green) and no traffic-splitting infrastructure (unlike Canary). At any point during the rollout, both the old version and the new version are running simultaneously — requests are distributed across both generations of instances by the load balancer.

The key constraint is backward compatibility during the overlap window. Because both versions handle production requests simultaneously, the API contract and database schema must be readable and writable by both versions. Rolling deployment is not "zero downtime" by default — it is "reduced disruption" deployment. Downtime is eliminated only when maxUnavailable: 0 is configured and maxSurge is non-zero (new instances must start before old ones are removed).

Rolling deployment is the default Kubernetes deployment strategy (.spec.strategy.type: RollingUpdate). Its simplicity makes it the appropriate default for low-risk, backward-compatible changes. For high-risk changes, prefer Blue-Green-Deployment (instant rollback). For gradual validation with metric gates, prefer Canary-Release-Pattern.

When NOT to Use

• Services with in-memory session state: If instances hold session state in memory, users served by old instances lose state when those instances are replaced mid-rollout. See the stateless requirement callout below.
• Non-backward-compatible API contract or DB schema: During the overlap window, requests hit both old and new instances. If the new version changes a response field that the old version produces differently, clients receive inconsistent responses depending on which instance they hit.
• High-risk changes requiring instant rollback: Rolling rollback requires re-rolling all instances back to the previous version — it is slow. Use Blue-Green-Deployment when rollback speed is critical.
• Changes that require validation with small traffic percentage first: Rolling does not provide a controlled small-percentage traffic gate. Use Canary-Release-Pattern for incremental validation.

When to Use

• Low-risk changes with backward-compatible API: Patch releases, internal refactors, and config-driven changes that do not alter the API contract or DB schema.
• Cost-constrained environments: No double capacity required; no canary traffic-splitting infrastructure required. Rolling is built into Kubernetes and most container orchestrators at zero additional cost.
• Stateless services with externalized session state: Services that store sessions in Redis, a database, or a distributed cache can be rolled without any session-loss risk.
• Default deployment strategy when neither Blue/Green nor Canary complexity is justified: For most day-to-day releases, Rolling is the correct default. Reserve Blue/Green and Canary for releases that warrant their overhead.

How It Works

Start (10 instances of v1.2):
  [v1.2] [v1.2] [v1.2] [v1.2] [v1.2] [v1.2] [v1.2] [v1.2] [v1.2] [v1.2]

Mid-rollout (maxSurge=1, maxUnavailable=1):
  [v1.3] [v1.3] [v1.2] [v1.2] [v1.2] [v1.2] [v1.2] [v1.2] [v1.2] [v1.2]
  ← Load balancer distributes across all healthy instances (both versions)

Complete:
  [v1.3] [v1.3] [v1.3] [v1.3] [v1.3] [v1.3] [v1.3] [v1.3] [v1.3] [v1.3]

Key parameters (Kubernetes RollingUpdate):

• maxSurge: Number (or percentage) of extra instances allowed above the desired replica count during rollout. maxSurge: 1 means one new instance starts before one old instance is removed.
• maxUnavailable: Number (or percentage) of instances allowed to be unavailable during rollout. maxUnavailable: 0 means all old instances remain serving traffic until a new instance is healthy.

Rollback in rolling deployment requires re-rolling all instances back to the previous version — each instance must be replaced again. This makes rollback slower than Blue/Green (router switch) or Canary (reduce weight to 0).

Pitfall — Rolling deployment requires stateless services: If instances hold in-memory session state, users served by old instances lose state when those instances are replaced mid-rollout. Externalize all session state to Redis, a database, or a distributed cache before using rolling deployment.

Deployment Diagram

flowchart TB
    LB[Load Balancer]

    subgraph Stage1["Stage 1 -- Start (10x v1.2)"]
        direction LR
        S1_1["v1.2"] ~~~ S1_2["v1.2"] ~~~ S1_3["v1.2"] ~~~ S1_4["v1.2"] ~~~ S1_5["...x10"]
    end

    subgraph Stage2["Stage 2 -- Mid-rollout (maxSurge=1, maxUnavailable=1)"]
        direction LR
        S2_NEW1["v1.3 NEW"] ~~~ S2_NEW2["v1.3 NEW"] ~~~ S2_OLD1["v1.2"] ~~~ S2_OLD2["v1.2"] ~~~ S2_OLD3["...x8"]
    end

    subgraph Stage3["Stage 3 -- Complete (10x v1.3)"]
        direction LR
        S3_1["v1.3"] ~~~ S3_2["v1.3"] ~~~ S3_3["v1.3"] ~~~ S3_4["v1.3"] ~~~ S3_5["...x10"]
    end

    LB --> Stage1
    Stage1 -->|"replace instances<br/>one by one"| Stage2
    Stage2 -->|"continue until<br/>all replaced"| Stage3

    RB["Rollback: re-roll all<br/>instances back to v1.2<br/>(slower than Blue/Green)"]
    Stage2 -.->|"on failure"| RB

    style Stage1 fill:#e6ffe6,stroke:#4a9d4a
    style Stage2 fill:#fff3e6,stroke:#d98c00
    style Stage3 fill:#e6f3ff,stroke:#4a90d9

TypeScript Example

// Rolling Deployment — TypeScript (typed interface showing rollout config)
// Source: Kubernetes documentation — RollingUpdate strategy
// NOT application code — this is a Kubernetes Deployment strategy configuration.
 
interface RollingUpdateConfig {
  maxSurge: number | string;        // e.g., 1 or '25%' — extra instances during rollout
  maxUnavailable: number | string;  // e.g., 0 or '25%' — instances allowed down during rollout
  // STATELESS REQUIREMENT: rolling deployment requires stateless services.
  // In-memory session state is lost when old instances are replaced mid-rollout.
  // Externalize session state to Redis or DB before using rolling deployment.
}

Java Example

// Rolling Deployment — Java (typed interface showing rollout config)
// Source: Kubernetes documentation — RollingUpdate strategy
// NOT application code — this is a Kubernetes Deployment strategy configuration.
 
public record RollingUpdateConfig(
    String maxSurge,        // e.g., "1" or "25%" — extra instances during rollout
    String maxUnavailable   // e.g., "0" or "25%" — instances allowed down during rollout
    // STATELESS REQUIREMENT: rolling deployment requires stateless services.
    // In-memory session state is lost when old instances are replaced mid-rollout.
    // Externalize session state to Redis or DB before using rolling deployment.
) {}

For the suitability comparison table (Blue/Green vs Canary vs Rolling), see Blue-Green-Deployment#Choosing a Release Strategy.

Lineage Backward

[[Blue-Green-Deployment]] (higher-cost alternative for high-risk changes), [[Canary-Release-Pattern]] (gradual-validation alternative), [[12-Factor-App]] (Factor VI — Stateless Processes is a prerequisite)

Lineage Forward

[[Deployment-Patterns-MOC]]

Related Concepts

Sources

• Kubernetes documentation — kubernetes.io/docs/concepts/workloads/controllers/deployment/ — RollingUpdate strategy (maxSurge, maxUnavailable); authoritative for Rolling deployment parameters
• Newman, Sam. Building Microservices, 2nd ed., O'Reilly, 2021 — deployment strategy trade-offs in microservices contexts

Backlinks

Notes that link here: Blue-Green-Deployment, 12-Factor-App