Blue-Green vs Canary Deployments

Blue-green deployment maintains two identical production environments and switches traffic between them for instant rollback. Canary deployment gradually routes a small percentage of traffic to the new version, monitoring for issues before full rollout.

What It Really Means

Deployment is the riskiest moment in a software system's lifecycle. A new version might have a bug that only manifests under production traffic, a performance regression that only appears at scale, or an incompatibility with production data. The goal of deployment strategies is to minimize the impact of these problems by controlling how traffic shifts to the new version.

Blue-green is the "big switch" approach: you have two identical environments (blue and green). One serves all traffic while the other is idle. You deploy the new version to the idle environment, test it, then switch all traffic at once. If something goes wrong, switch back immediately.

Canary is the "gradual rollout" approach: you deploy the new version alongside the current one and route a small percentage (1-5%) of traffic to it. If the canary version performs well (no errors, no latency increase), you gradually increase traffic (10%, 25%, 50%, 100%). If problems appear, you route all traffic back to the old version.

Both strategies solve the same problem — safe deployments — but with different trade-offs in speed, cost, and risk detection.

How It Works in Practice

Blue-Green Deployment

Canary Deployment

Rolling Deployment (Alternative)

Implementation

Kubernetes canary with Istio traffic splitting:

Automated canary analysis (conceptual):

Blue-green with AWS ALB:

Trade-offs

Choose blue-green when:

• You need instant rollback (< 1 second)
• The cost of two environments is acceptable
• You want simplicity (one switch, not gradual ramp)
• Testing the full environment before switching is valuable

Choose canary when:

• You want to minimize blast radius
• You have automated metrics comparison
• Your traffic volume is high enough to detect issues at 1-5% (need statistical significance)
• You can tolerate running two versions simultaneously

Database migration challenge: Both strategies must handle database schema changes carefully. The new version's code must work with both the old and new schema during the transition period. This usually requires backward-compatible migrations deployed separately from application code.

Common Misconceptions

• "Blue-green is safer than canary" — Blue-green switches 100% of traffic at once. If a bug only appears under full load, you expose all users. Canary limits exposure to a small percentage.
• "Canary deployments catch all bugs" — Canary only catches bugs that manifest in the percentage of traffic it receives. A bug affecting 0.01% of requests may not trigger at 1% canary traffic with statistical significance.
• "You need separate infrastructure for blue-green" — With containers and Kubernetes, blue-green can use the same cluster with different deployments. Separate physical infrastructure is not required.
• "Rolling deployments are obsolete" — Rolling deployments are simpler, cheaper, and sufficient for many applications. Not every system needs the complexity of blue-green or canary.
• "Feature flags replace deployment strategies" — Feature flags control feature visibility. Deployment strategies control code deployment. Use both together: deploy via canary, enable features via flags.

How This Appears in Interviews

1. "How do you deploy changes safely?" — Describe canary deployment with automated metric comparison, error budget monitoring, and automatic rollback on SLO violation.
2. "How do you handle database schema changes during deployment?" — Backward-compatible migrations, expand-and-contract pattern, deploy migration separately from code.
3. "Design a deployment pipeline for a microservice" — CI/CD with automated tests, canary deployment to production, automated analysis comparing canary vs baseline SLIs, progressive traffic shifting.
4. "What happens if a deployment goes wrong?" — Automated rollback triggered by error rate spike, tail latency increase, or error budget consumption. Discuss blast radius and detection time.

Related Concepts

• SLOs, SLIs, and SLAs — canary analysis compares against SLO targets
• Tail Latency — canary analysis monitors latency percentiles
• Chaos Engineering — test deployment rollback procedures with chaos experiments
• CDN and Edge Computing — edge deployments use canary patterns across regions
• System Design Interview Guide
• Algoroq Pricing — access all concept deep-dives