Rolling Deployment: Mermaid Flowchart Diagram

About Source

A rolling deployment updates a fleet of servers one batch at a time, replacing old instances with new ones incrementally until the entire fleet runs the new version — maintaining capacity throughout the process without requiring a separate standby environment.

What the diagram shows

The diagram shows a fleet of four server instances initially all running v1.0. The deployment orchestrator begins with Batch 1: Instance 1 is taken out of the load balancer rotation, updated to v2.0, health-checked, and returned to service before the next batch starts. This process repeats for Batch 2 (Instance 2), Batch 3 (Instance 3), and Batch 4 (Instance 4).

During each batch update, the remaining instances at v1.0 continue serving traffic, so total serving capacity is reduced by 25% per batch but never drops to zero. If a health check fails on a newly updated instance, the orchestrator halts the rollout and the failed instance is reverted to v1.0.

Why this matters

Rolling deployments are the simplest zero-downtime strategy to operate because they require no extra infrastructure — you update the fleet you already have. The challenge is that during the rollout window, both v1.0 and v2.0 are serving production traffic simultaneously. This means your API must be backward-compatible with requests from both versions, and database schema migrations must be additive rather than destructive. For a strategy that avoids mixed-version production, see Blue Green Deployment. For gradual traffic shifting with metric gates, see Canary Deployment.

Frequently asked questions

A rolling deployment updates a fleet of servers in sequential batches — taking each batch out of rotation, updating it to the new version, health-checking it, and returning it to service before starting the next batch — maintaining capacity throughout without requiring a duplicate environment.

The orchestrator divides the fleet into batches (e.g., one instance at a time or 25% at a time). For each batch: remove from load balancer rotation → update to new version → run health checks → re-add to rotation. If a health check fails, the rollout halts and the failed instance reverts to the previous version.

Use rolling deployments when you want zero-downtime releases without the infrastructure cost of blue-green (which requires a full duplicate environment). They are well-suited to Kubernetes deployments, where the orchestrator handles batching and health checks automatically.

mermaid

flowchart TD
    Start([Fleet: 4 instances\nall running v1.0]) --> Batch1

    subgraph Batch1[Batch 1]
        B1_Remove[Remove Instance 1\nfrom load balancer]
        B1_Update[Update Instance 1\nto v2.0]
        B1_Health{Health\nCheck}
        B1_Restore[Return Instance 1\nto rotation]
        B1_Remove --> B1_Update --> B1_Health
        B1_Health -->|Pass| B1_Restore
        B1_Health -->|Fail| B1_Revert[Revert Instance 1\nHalt rollout]
    end

    B1_Restore --> Batch2

    subgraph Batch2[Batch 2]
        B2[Update Instance 2\nto v2.0 - Health Check]
    end

    Batch2 --> Batch3

    subgraph Batch3[Batch 3]
        B3[Update Instance 3\nto v2.0 - Health Check]
    end

    Batch3 --> Batch4

    subgraph Batch4[Batch 4]
        B4[Update Instance 4\nto v2.0 - Health Check]
    end

    Batch4 --> Done([All instances\nrunning v2.0])