Zero-Downtime Deployments — Ship Every Day Without Taking Down the Service

Rolling Deployment: New instances are added to the load balancer, verified healthy, and then old instances are removed one at a time. At any point during the deployment, both old and new versions are serving traffic simultaneously. This is the simplest strategy and works well when the old and new versions are compatible (they share the same database schema and API contracts). Most ECS and Kubernetes deployments use this strategy by default.

Blue-Green Deployment: The new version (green) is deployed alongside the current version (blue) as a complete, independent environment. Traffic is switched from blue to green all at once (via DNS, load balancer, or weighted routing). If the green environment has problems, traffic switches back to blue immediately. This avoids the mixed-version period of rolling deployments but requires double the infrastructure during the switch.

Canary Deployment: A small percentage of traffic (1-10%) is routed to the new version while the rest continues on the current version. If the canary shows errors, high latency, or anomalous behavior, the deployment is rolled back before affecting most users. If the canary is healthy, traffic is gradually shifted until 100% is on the new version. This is the safest strategy for high-traffic applications where a bad deployment affects millions of users.

The right strategy depends on your risk tolerance, traffic volume, and infrastructure budget. We recommend rolling deployments for most applications, canary for high-traffic production services, and blue-green for applications where mixed-version traffic is problematic.

Health Check Integration: The deployment only proceeds when new instances pass health checks. We implement deep health checks that verify database connectivity, cache connectivity, and critical dependency availability — not just HTTP 200 on a static path. Health check grace periods account for application startup time so slow-starting applications are not killed prematurely.

Connection Draining: Before removing an old instance, we configure a deregistration delay that allows in-flight requests to complete. The load balancer stops sending new requests but maintains existing connections for 30-60 seconds (configurable). The application handles SIGTERM gracefully — stops accepting new work, completes in-progress requests, closes database connections, and then exits.

Database Migration Safety: The hardest part of zero-downtime deployments is database migrations. We enforce expand-contract patterns: first deploy a version that adds new columns/tables (expand), then deploy a version that uses the new schema and stops using the old (contract), then remove old columns in a later deploy. This ensures both the old and new application versions work with the database at every point during the deployment.

Specific migration safety rules: never drop a column in the same deploy that stops using it, never rename a column (add new, migrate data, drop old), never add a NOT NULL column without a default value (locks the table on large datasets in some databases), and use CREATE INDEX CONCURRENTLY in PostgreSQL to avoid locking reads during index creation.

Rollback: Every deployment can roll back to the previous version within seconds. For rolling and canary deployments, rollback means scaling the old version back up and the new version down. For blue-green, rollback means switching traffic back to the blue environment. We wire rollback into the CI/CD pipeline as an automated response to failed health checks and as a manual option for discovered issues.

A complete zero-downtime deployment setup:

• Deployment strategy — rolling, blue-green, or canary configured for your platform (ECS, EKS, bare metal)
• Health check integration — deep health checks with appropriate grace periods and thresholds
• Connection draining — graceful shutdown with in-flight request completion
• Database migration patterns — expand-contract workflow enforced via CI checks
• Automatic rollback — health-check-triggered rollback with immediate traffic redirection
• Canary analysis — optional automated canary metrics comparison (error rate, latency)
• Deployment notifications — Slack/Teams alerts on deploy start, health check status, and completion
• Runbook — deployment procedures, rollback steps, and troubleshooting guide