Zero-Downtime Deployments

The deployment window is a relic. Scheduled maintenance pages, late-night deploys, crossing fingers and hoping—none of this should exist in 2026. Your users shouldn’t know when you deploy. They shouldn’t care.

Zero-downtime deployment isn’t magic. It’s engineering discipline applied to a specific problem: how do you replace running code without dropping requests?

The Fundamental Challenge

During deployment, you have two versions of your application:

Old version: Currently serving traffic
New version: Ready to serve traffic

The challenge: transition from old to new without dropping connections or serving errors.

Strategy 1: Rolling Deployment

The simplest approach. Replace instances one at a time.

How it works:

Start a new instance with v2
Wait for health checks to pass
Add v2 to load balancer
Remove one v1 from load balancer
Terminate v1 instance
Repeat until all v1 replaced

Kubernetes example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

Pros:

Simple to implement
Low resource overhead (only one extra instance at a time)
Gradual rollout catches issues early

Cons:

Both versions serve traffic simultaneously
Database migrations must be backward compatible
Rollback requires another rolling deployment

Strategy 2: Blue-Green Deployment

Run two identical environments. Switch traffic all at once.

Implementation with AWS ALB:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
# Deploy v2 to green target group
aws ecs update-service --cluster prod --service green --task-definition myapp:v2

# Wait for healthy
aws ecs wait services-stable --cluster prod --services green

# Switch ALB listener
aws elbv2 modify-listener --listener-arn $LISTENER_ARN \
  --default-actions Type=forward,TargetGroupArn=$GREEN_TG_ARN

# Rollback is just switching back
aws elbv2 modify-listener --listener-arn $LISTENER_ARN \
  --default-actions Type=forward,TargetGroupArn=$BLUE_TG_ARN

Pros:

Instant rollback (just switch back)
Clean separation between versions
Easy to test green before switching

Cons:

Double the infrastructure cost (temporarily)
Database must support both versions during switch
DNS propagation if using DNS-based switching

Strategy 3: Canary Deployment

Route a small percentage of traffic to the new version. Increase gradually.

Nginx weighted upstream:

1
2
3
4
upstream backend {
    server v1.internal weight=95;
    server v2.internal weight=5;
}

AWS ALB weighted target groups:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
aws elbv2 modify-listener --listener-arn $LISTENER_ARN \
  --default-actions '[
    {
      "Type": "forward",
      "ForwardConfig": {
        "TargetGroups": [
          {"TargetGroupArn": "'$V1_TG'", "Weight": 95},
          {"TargetGroupArn": "'$V2_TG'", "Weight": 5}
        ]
      }
    }
  ]'

Pros:

Minimize blast radius of bugs
Real production traffic validation
Can abort at any point

Cons:

Requires good observability to detect issues
More complex routing logic
Users may see inconsistent behavior during rollout

The Database Problem

Code deploys are easy. Databases are hard.

The trap:

1
2
3
4
5
-- v1 expects: users(id, name, email)
-- v2 expects: users(id, full_name, email)  -- renamed column!

-- If you deploy v2 and migrate simultaneously:
-- v1 instances break immediately

The solution: Expand-Contract pattern

Phase 1: Expand (backward compatible)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
-- Add new column, keep old one
ALTER TABLE users ADD COLUMN full_name VARCHAR(255);

-- Backfill
UPDATE users SET full_name = name;

-- Add trigger to keep in sync
CREATE TRIGGER sync_name 
BEFORE INSERT OR UPDATE ON users
FOR EACH ROW EXECUTE FUNCTION sync_name_columns();

Deploy v2 that writes to both columns, reads from new column.

Phase 2: Contract (after all instances are v2)

1
2
3
-- Remove old column
ALTER TABLE users DROP COLUMN name;
DROP TRIGGER sync_name;

Timeline:

Deploy migration (expand)
Deploy v2 code
Wait for all v1 instances gone
Deploy cleanup migration (contract)

This adds complexity but prevents downtime.

Connection Draining

When removing an instance from rotation, don’t kill active connections.

The wrong way:

1
2
# Immediately kills all connections
docker stop myapp

The right way:

1
2
3
# Stop accepting new connections
# Wait for existing requests to complete
# Then shutdown

Implementation:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
import signal
import sys
from threading import Event

shutdown_event = Event()

def handle_sigterm(signum, frame):
    print("SIGTERM received, draining...")
    shutdown_event.set()
    # Stop accepting new requests
    # (implementation depends on your server)

signal.signal(signal.SIGTERM, handle_sigterm)

# In your health check endpoint
@app.route('/health')
def health():
    if shutdown_event.is_set():
        return "Draining", 503  # Tell LB to stop sending traffic
    return "OK", 200

Load balancer settings:

AWS ALB: deregistration_delay.timeout_seconds = 30
Kubernetes: terminationGracePeriodSeconds: 30

Health Checks That Work

Bad health checks cause downtime during deploys.

Too simple:

1
2
3
@app.route('/health')
def health():
    return "OK"  # Always returns OK, even when broken

Too complex:

1
2
3
4
5
6
7
@app.route('/health')
def health():
    check_database()
    check_redis()
    check_external_api()
    check_disk_space()
    return "OK"

If any dependency is slow, health checks fail, and your instance gets killed—even though it might be able to serve requests.

Just right:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
@app.route('/health/live')
def liveness():
    """Am I running? Kill me if not."""
    return "OK"

@app.route('/health/ready')
def readiness():
    """Can I serve traffic? Remove from LB if not."""
    if not database_pool.is_connected():
        return "Not ready", 503
    return "OK"

@app.route('/health/startup')
def startup():
    """Am I done initializing? Wait if not."""
    if not app_initialized:
        return "Starting", 503
    return "OK"

Kubernetes uses all three:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
livenessProbe:
  httpGet:
    path: /health/live
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 10

readinessProbe:
  httpGet:
    path: /health/ready
    port: 8080
  periodSeconds: 5

startupProbe:
  httpGet:
    path: /health/startup
    port: 8080
  failureThreshold: 30
  periodSeconds: 2

Graceful Startup

New instances need time before handling traffic.

Problems during cold start:

JIT compilation hasn’t warmed up
Caches are empty
Connection pools aren’t filled
Lazy-loaded resources aren’t loaded

Solution: Warm-up period

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
import time
from threading import Thread

app_ready = False

def warm_up():
    global app_ready
    # Pre-fill caches
    load_frequently_accessed_data()
    # Prime connection pools
    database.execute("SELECT 1")
    redis.ping()
    # Warm up hot paths
    run_typical_requests_internally()
    
    app_ready = True

# Start warmup in background
Thread(target=warm_up).start()

@app.route('/health/ready')
def readiness():
    if not app_ready:
        return "Warming up", 503
    return "OK"

Rollback Strategies

Deployment succeeded. Then metrics tank. Now what?

Rollback options:

Re-deploy previous version (slow)
- Works for any strategy
- Takes as long as a normal deploy
Blue-green switch (instant)
- Just change the pointer back
- Requires keeping old environment ready
Feature flag disable (instant)
- New code stays deployed
- Problematic feature turned off
- Requires feature flags built in
Traffic shift (instant)
- Canary: shift back to 0% new
- Keep new version for debugging

Automated rollback:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
deploy_and_monitor() {
    deploy_new_version
    
    for i in {1..10}; do
        sleep 30
        if ! check_error_rate_acceptable; then
            echo "Error rate too high, rolling back"
            rollback
            exit 1
        fi
    done
    
    echo "Deploy successful"
}

Putting It Together

A practical deployment pipeline:

Build artifact (container image, binary)
Test in staging environment
Deploy canary (5% traffic)
Monitor for 5 minutes
Gradual rollout (25% → 50% → 100%)
Monitor for 30 minutes
Cleanup old version

If any step fails, rollback automatically.

What you need:

Health checks (liveness, readiness, startup)
Connection draining
Backward-compatible database migrations
Observability (metrics, logs, alerts)
Automated rollback triggers

Zero-downtime deployment isn’t a feature you turn on. It’s a set of practices that, together, make “deploy whenever” safe and boring.

Boring is good. Boring means your users don’t notice.

The best deployment is the one nobody notices happened.

The Fundamental Challenge#

Strategy 1: Rolling Deployment#

Strategy 2: Blue-Green Deployment#

Strategy 3: Canary Deployment#

The Database Problem#

Connection Draining#

Health Checks That Work#

Graceful Startup#

Rollback Strategies#

Putting It Together#

📬 Get the Newsletter

The Fundamental Challenge

Strategy 1: Rolling Deployment

Strategy 2: Blue-Green Deployment

Strategy 3: Canary Deployment

The Database Problem

Connection Draining

Health Checks That Work

Graceful Startup

Rollback Strategies

Putting It Together