Zero Downtime Deployment: Mermaid Diagram

Zero Downtime Deployment flowchart diagram

About Source

Zero downtime deployment is the practice of releasing new software without interrupting service for any users — achieved by combining a suitable deployment strategy with backward-compatible database migrations, graceful connection draining, and health-gated traffic switching.

What the diagram shows

The diagram walks through the full zero downtime deployment workflow as a sequential decision tree. It begins with a Database Migration Check: the migration must be backward-compatible (additive only — new nullable columns, new tables) so that the old code version continues to work during the transition. If migration is not backward-compatible, the release is blocked for re-design.

Next, the Deployment Strategy selection branch chooses between Blue-Green, Canary, or Rolling based on team requirements. Regardless of strategy, new instances must pass a Readiness Probe before receiving traffic. Connection Draining ensures in-flight requests on old instances complete before those instances are terminated. A final Smoke Test against production confirms the new version is healthy before old instances are fully decommissioned.

Why this matters

Zero downtime is not a single technique but a combination of practices. The database migration constraint is the most commonly violated: a migration that drops a column or renames a table will break the old application version still serving traffic during rollout. For the specific deployment strategies referenced, see Blue Green Deployment, Canary Deployment, and Rolling Deployment.

Frequently asked questions

Zero downtime deployment is the practice of releasing new software without interrupting service for any user — achieved by combining a deployment strategy (blue-green, canary, or rolling) with backward-compatible database migrations, readiness probes, and graceful connection draining.

The process starts with verifying database migrations are backward-compatible. A deployment strategy routes traffic only to instances that have passed readiness probes. In-flight requests on old instances are drained before termination. A final smoke test confirms the new version is healthy before old instances are decommissioned.

Use zero downtime deployment for any production service where an interruption impacts users or revenue — which is most web services. Even brief maintenance windows erode user trust and violate SLAs. Zero downtime techniques are now standard practice and tools like Kubernetes rolling updates implement them by default.

mermaid

flowchart TD
    Start([New Release Ready]) --> MigCheck{DB Migration\nBackward Compatible?}
    MigCheck -->|No| Block[Block Release\nRedesign Migration]
    MigCheck -->|Yes| RunMigration[Run Additive\nDB Migration]
    RunMigration --> Strategy{Choose\nDeployment Strategy}
    Strategy -->|Low risk| BlueGreen[Blue-Green\nFull env switch]
    Strategy -->|Gradual rollout| Canary[Canary\nTraffic shifting]
    Strategy -->|In-place update| Rolling[Rolling\nBatch updates]
    BlueGreen --> ReadinessProbe[Readiness Probe\nNew instances healthy?]
    Canary --> ReadinessProbe
    Rolling --> ReadinessProbe
    ReadinessProbe -->|Fail| RollbackDeploy[Rollback\nRestore old version]
    ReadinessProbe -->|Pass| Drain[Connection Draining\nFinish in-flight requests]
    Drain --> SwitchTraffic[Switch Traffic\nto New Instances]
    SwitchTraffic --> SmokeTest{Smoke Test\nPassed?}
    SmokeTest -->|Fail| RollbackDeploy
    SmokeTest -->|Pass| Decommission[Decommission\nOld Instances]