Blue-Green Deployment
establishedSummary
Maintain two identical production environments (blue and green). Route all traffic to the active environment while deploying and validating the new version in the idle environment. Swap traffic atomically when validation passes, enabling instant rollback by swapping back.
Problem
Traditional deploy-in-place strategies cause a downtime window during deployment (service unavailable while old code is stopped and new code starts) and require redeployment for rollback (minutes of risk exposure). Blue-green eliminates the downtime window and reduces rollback to a traffic re-route taking seconds.
Description
Blue-green deployment eliminates deployment downtime and minimizes rollback time. Two environments: "blue" (currently active) and "green" (standby): are kept in identical configuration. When a new version is ready:
1. Deploy new version to the idle (green) environment. 2. Run smoke tests, health checks, and validation against green with no production traffic. 3. Shift traffic: update the load balancer or DNS to route production traffic to green. 4. Monitor green under production load. If metrics degrade, shift traffic back to blue (rollback). 5. After confidence window passes, decommission or update blue for the next deployment.
The traffic shift can be instantaneous (load balancer rule update) or gradual (canary: 1% → 10% → 100%). The key property is that rollback is a traffic re-route, not a code deploy: it takes seconds, not minutes.
Database schema changes are the primary complication. If the new version requires a schema change, the schema must be backward-compatible with both old and new code during the transition window. Rolling back the application code but not the schema change requires the old code to work with the new schema. This requires expand-contract migrations: first add new columns/tables (expand), deploy new code that reads both, then remove old columns (contract) in a later migration after all traffic is on new code.
Load balancer rule update (AWS ALB): maintain two target groups (blue-tg, green-tg) and update the listener rule weight, blue-tg to 0%, green-tg to 100%, for the swap (aws elbv2 modify-rule --actions Type=forward,ForwardConfig=...).
DNS-based cutover: update Route53 weighted records to shift traffic. This has higher propagation latency than a load balancer rule update and is not recommended when instant rollback matters.
Database expand-contract in three phases: expand (ALTER TABLE ADD COLUMN new_col; deploy code reading new_col with fallback to old_col), cutover (switch all writes to new_col; shift traffic to green), and contract (after the confidence window, ALTER TABLE DROP COLUMN old_col).
Tradeoffs
Zero downtime deployments; traffic is served continuously from one environment while the other is updated
Instant rollback by shifting traffic back to the previous environment
Validates under real infrastructure before the traffic shift
Clean separation between deployment (code in place) and release (traffic shift)
2x infrastructure footprint during deployment windows
Database schema changes require backward-compatible expand-contract migrations
Long-running transactions at traffic cutover may be disrupted and require graceful connection draining
If green is idle between deployments, resources are wasted; auto-scaling to zero and restoring on deploy adds complexity
When to use
Service must maintain continuous availability during deployments
If downtime is acceptable, blue-green adds infrastructure complexity for no benefit
Rollback capability within seconds is a business requirement
If a deployment introduces a regression, blue-green allows instant traffic re-route to the old version
Infrastructure can provision two identical environments
Blue-green requires 2× the infrastructure footprint during the transition window
Schema changes can be made backward-compatible across two code versions
Non-backward-compatible schema changes force a coordinated cutover, eliminating blue-green's benefit
When not to use
Infrastructure cannot afford 2× footprint during deployment
Blue-green requires running both environments simultaneously; this is the primary cost
State is stored on application instances (in-process caches, local files)
State on instances means the two environments have different state; warm-up is required
Operational Requirements
Drain connections from blue before decommissioning
Active long-lived connections need a graceful shutdown window.
Monitor green's health metrics before decommissioning blue
Watch for at least 10 minutes after the traffic shift before decommissioning blue.
Implement readiness probes before routing traffic to a new instance
Verify application and database connectivity, not just process liveness.
Automate the traffic shift
A manual load balancer update is a production change and should have a runbook and approval.
Characteristics
Relationships
Complements
Basis
Blue-green deployment is a well-documented deployment strategy in Martin Fowler's bliki, AWS documentation, and Kubernetes rolling update documentation; expand-contract database migration pattern is documented in evolutionary database design literature
Related Architecture Knowledge
Outbound: this entity affects
Health checks validate the new blue-green environment before traffic shift, ensuring the switch is only made when the new version is confirmed ready to serve requests.
Full relationship →Strangler fig incrementally replaces legacy system components with new implementations; blue-green deployment provides zero-downtime switching between old and new components as each strangler fig increment is completed.
Full relationship →Blue-green deployment pre-warms the new environment (connections, caches, JIT) before traffic shifts, eliminating cold-start latency that would otherwise occur during in-place deployments.
Full relationship →