Deployment Strategies: Zero-Downtime, Blue-Green, Canary, and Progressive Delivery

Deploying software updates to high-traffic production systems requires eliminating downtime, minimizing blast radius, and automating rollbacks if regressions occur. This guide covers the architectural mechanics of Rolling Updates, Blue/Green cutovers, Canary traffic shifting, Shadow launches, and backward-compatible database schema migrations.

⚡ Quick Dive

Deployment Strategies Comparison Matrix

Strategy Downtime Risk Rollback Speed Infrastructure Cost Blast Radius State / DB Complexity
Recreate ⚠️ High (Service outage) Slow (Re-deploy old version) 1x (No extra hardware) 100% of users Low (No mixed versions)
Rolling Update ✅ Zero Medium (Roll back pod by pod) 1x - 1.25x (maxSurge) Medium (Mixed versions live) High (Requires backward compatibility)
Blue / Green ✅ Zero ⚡ Instant (Switch router pointer) 2x (Full duplicate environment) 100% on cutover Medium
Canary ✅ Zero ⚡ Fast (Route traffic back) 1.1x - 1.5x Minimal (1% $\to$ 10% $\to$ 100%) High (Mixed versions live)
Shadow / Dark ✅ Zero N/A (Zero production impact) 2x (Mirror traffic) 0% (Users never see shadow) High (Duplicate writes risk)

📖 Extended Guide

1. Architectural Deep Dives

1. Rolling Update (Kubernetes Default)

Gradually replaces instances of previous version (v1) with new version (v2) without taking the entire service offline:

Step 1: [ v1 ][ v1 ][ v1 ][ v1 ]
Step 2: [ v1 ][ v1 ][ v1 ][ v2 ] (25% v2)
Step 3: [ v1 ][ v1 ][ v2 ][ v2 ] (50% v2)
Step 4: [ v2 ][ v2 ][ v2 ][ v2 ] (100% v2)

# Kubernetes Rolling Update Strategy
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25% # Max pods created above desired count during rollout
      maxUnavailable: 0 # Zero pods allowed down during rollout (Guarantees zero downtime)

2. Blue/Green Deployment

Maintains two identical production environments: Blue (Active live traffic) and Green (Idle / Staging).

                    ┌─────────────────────────┐
                    │ Router / Load Balancer  │
                    └────────────┬────────────┘
                                 │
                 ┌───────────────┴───────────────┐
                 ▼ (Active Live)                 │ (Deploy & Smoke Test v2)
       ┌──────────────────┐            ┌──────────────────┐
       │  Blue Pool (v1)  │            │  Green Pool (v2) │
       └──────────────────┘            └──────────────────┘
  1. Deploy version 2 to Green.
  2. Run automated integration & health checks on Green.
  3. Switch Load Balancer router target from Blue to Green instantly.
  4. If an anomaly occurs, switch router back to Blue within milliseconds.

3. Canary Releases & Progressive Delivery

Routes a tiny fraction of live user traffic (e.g., 5%) to version 2 while monitoring metrics (error rates, p99 latency).

User Requests ──► Load Balancer / Service Mesh
                     ├── 95% ──► [ v1 Stable Pods ]
                     └──  5% ──► [ v2 Canary Pods ] ──► (Prometheus Metric Analysis)

If metrics stay healthy over 15 minutes, increase traffic (5% $\to$ 25% $\to$ 50% $\to$ 100%). If error rates spike, automatically drop canary traffic back to 0%.

2. Database Schema Migrations: The Expand-Contract Pattern

[!CAUTION] Zero-downtime application deployments will crash if database migrations make breaking changes (e.g. renaming a column) while older application pods are still running.

The 4-Phase Expand-Contract Migration Workflow:

Phase 1 (Expand): Add new column 'full_name' alongside old 'first_name' and 'last_name'.
Phase 2 (Dual Write): Deploy application code that reads from 'first_name' but writes to BOTH.
Phase 3 (Backfill): Run background worker to backfill data into 'full_name'.
Phase 4 (Contract): Deploy app reading strictly from 'full_name'. Drop old columns safely.
⌂ All Guides