Zero Downtime Deployments

Zero downtime deployment is a set of practices rather than one tool. The infrastructure swaps instances gracefully, and the application and data layers stay compatible across versions so that old and new code can coexist.

How it works

An orchestrator starts new instances and waits for readiness checks before adding them to the load balancer. It then signals old instances to shut down. Those instances stop accepting new requests, finish in-flight work within a grace period, close connections, and exit. A surge or unavailable limit controls how many instances change at once. Database changes follow expand and contract: add new structures first, deploy code that works with both, migrate data, and remove the old structures in a later release.

Implementation steps

1. Run at least two instances behind a load balancer
2. Implement accurate readiness and liveness checks
3. Handle termination signals with connection draining and a grace period
4. Apply expand and contract database migrations
5. Control rollout speed with surge and unavailable limits
6. Automate verification and rollback on failed health or error thresholds

Common pitfalls

• Readiness checks that pass before the application can actually serve
• Grace periods shorter than the longest request
• Migrations that lock tables or drop columns the old version still uses
• Ignoring long-lived connections such as websockets

Metrics to watch

• Errors and dropped requests during rollout
• Rollout duration
• Number of failed or rolled back releases
• Time to drain instances
• Error rate during mixed version periods

Example configuration

# Kubernetes rolling update
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      terminationGracePeriodSeconds: 45
      containers:
        - name: app
          readinessProbe:
            httpGet: { path: /ready, port: 8080 }

Trade-offs and adoption

Teams adopt this approach when services must stay available during releases; releases happen frequently, often several times daily. It is a poor fit when single-instance systems without redundancy where brief downtime is accepted, or when changes that fundamentally cannot run beside the previous version. The central tensions are release speed vs compatibility effort; extra capacity vs rollout safety; simplicity vs gradual exposure. The main benefits are that it delivers: no user-facing interruptions during release; encourages small, frequent deployments; reduces release stress and weekend work; rolling approach needs little extra capacity. The main costs to budget for are: requires backward and forward compatibility; mixed versions run simultaneously for a time; needs correct health checks and graceful shutdown; database changes demand multi-step planning. Governance typically looks like this: engineering standards require compatibility rules and automated rollout checks. Expect adoption cost to be medium: orchestration, health checks, and migration discipline, and a best fit for teams of any size running redundant services. Critics point out that schema compatibility rules slow feature work and are often broken by accident, and that rolling updates provide less isolation than blue-green when a defect appears. Treat these concerns as design inputs, and revisit the decision as traffic, team size, and failure history change.

Key takeaways

• Gate traffic on real readiness and drain on shutdown
• Keep adjacent versions compatible
• Change schemas with expand and contract steps
• Automate rollback so releases are routine