Home/Learn/System Design/Blue-Green & Canary Deployments

Blue-Green & Canary Deployments

Intermediate

Observability & Operations

Blue-green deployment maintains two identical environments and switches traffic instantly. Canary deployment gradually routes a small percentage of traffic to the new version. Both enable zero-downtime releases with easy rollback.

Overview

Traditional deployments risk downtime and hard-to-reverse failures. Blue-green deployment maintains two identical production environments: Blue (current) and Green (new version). You deploy the new version to Green, test it, then switch the load balancer/DNS from Blue to Green. Rollback is instant — switch back to Blue. Canary deployment is more gradual: deploy the new version to a small subset of servers (1-5% of traffic), monitor error rates and latency, and gradually increase traffic (10%, 25%, 50%, 100%) if metrics are healthy. If problems are detected, traffic is routed back to the old version. Canary is less risky than blue-green because failures only affect a small percentage of users. Both strategies require good monitoring and automated rollback capabilities. Kubernetes supports both via Deployment strategies and Istio traffic splitting.

Blue-Green Deployment

Two identical environments. Deploy to the idle one, test, then switch all traffic. Rollback by switching back.

Conceptual + Terraform — blue-green switch

// Blue-Green deployment flow
//
// Step 1: Blue (v1) is live, Green is idle
//   Load Balancer → Blue (v1) [100% traffic]
//                   Green (idle)
//
// Step 2: Deploy v2 to Green, run smoke tests
//   Load Balancer → Blue (v1) [100% traffic]
//                   Green (v2) [smoke tests pass ✅]
//
// Step 3: Switch traffic to Green
//   Load Balancer → Green (v2) [100% traffic]
//                   Blue (v1) [idle, ready for rollback]
//
// Step 4: If problems → instant rollback to Blue
//   Load Balancer → Blue (v1) [100% traffic]

// AWS: Route 53 weighted routing for blue-green
resource "aws_route53_record" "api" {
  zone_id        = var.zone_id
  name           = "api.example.com"
  type           = "A"
  set_identifier = "green"
  weighted_routing_policy { weight = 100 }  # all traffic to green
  alias { name = aws_lb.green.dns_name }
}

Canary Deployment

Route a small percentage of traffic to the new version. Monitor metrics. Gradually increase if healthy. Roll back if error rate or latency degrades.

Istio + Argo YAML — automated canary deployment

// Canary deployment flow
//
// Step 1: Deploy v2 to canary (1% traffic)
//   LB → v1 [99%] + v2 [1%]  ← monitor error rate, latency
//
// Step 2: Metrics healthy → increase to 10%
//   LB → v1 [90%] + v2 [10%]
//
// Step 3: Still healthy → 50%
//   LB → v1 [50%] + v2 [50%]
//
// Step 4: Full rollout → 100%
//   LB → v2 [100%]
//
// If error rate spikes at any step → rollback to v1 [100%]

// Istio canary with traffic splitting
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: order-service
spec:
  hosts:
    - order-service
  http:
    - route:
        - destination:
            host: order-service
            subset: stable    # v1
          weight: 90
        - destination:
            host: order-service
            subset: canary    # v2
          weight: 10

// Argo Rollouts — automated canary with analysis
apiVersion: argoproj.io/v1alpha1
kind: Rollout
spec:
  strategy:
    canary:
      steps:
        - setWeight: 5
        - pause: { duration: 5m }     # observe for 5 min
        - analysis:                     # check error rate
            templates:
              - templateName: error-rate-check
        - setWeight: 25
        - pause: { duration: 10m }
        - setWeight: 50
        - pause: { duration: 10m }
        - setWeight: 100

Key Points to Remember

1Blue-green: two identical envs, instant switch, instant rollback — simple but doubles infrastructure.
2Canary: gradual traffic shift (1% → 10% → 50% → 100%) — less risky, needs good monitoring.
3Both require automated monitoring and rollback based on error rate, latency, and business metrics.
4Kubernetes + Istio + Argo Rollouts enable automated canary with traffic splitting and analysis.
5Always have a rollback plan — "what happens if the new version breaks?"

Interview Questions

What is the difference between blue-green and canary deployments?

EasyTCS

How do you decide when to promote or rollback a canary deployment?

MediumAmazon

How does Istio enable traffic splitting for canary deployments?

MediumGoogle

What are the costs of blue-green deployment compared to canary?

MediumFlipkart

Design a zero-downtime deployment pipeline for 50 microservices.

HardNetflix

Ask Aria about Blue-Green & Canary Deployments

Your personal AI tutor — ask anything about this concept

Revision Status

Personal Notes

Discussion

Loading discussion…

Distributed Tracing

Chaos Engineering