Home/Learn/Microservices/Blue-Green Deployment

Blue-Green Deployment

Intermediate

Deployment

Run two identical production environments; switch the load-balancer to the new (green) release instantly, with the old (blue) kept on standby for instant rollback.

Overview

Blue-green deployment maintains two identical production environments (blue = current live, green = new version). The new version is deployed to the green environment, fully tested in isolation, then traffic is switched from blue to green in a single atomic operation by updating the load-balancer or DNS. If the new version has issues, rollback is instant — switch back to blue. The primary advantage over canary is simplicity: no partial traffic state, no mixed version database schema issues. The primary disadvantage is cost (double infrastructure) and the cold start problem — green sits idle until cutover. In Kubernetes, blue-green is implemented by pointing the Service selector to blue or green Deployment labels.

Kubernetes blue-green with Service label selector

Run two Deployments (blue and green) simultaneously. The Service routes to whichever Deployment matches the active label. Switching is an atomic label update.

YAML — Kubernetes blue-green Deployments + Service

# blue deployment (currently live)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service-blue
  labels:
    app: order-service
    version: blue
spec:
  replicas: 5
  selector:
    matchLabels:
      app: order-service
      version: blue
  template:
    metadata:
      labels:
        app: order-service
        version: blue
    spec:
      containers:
        - name: order-service
          image: order-service:v1.2.0

# Service — currently pointing to blue
apiVersion: v1
kind: Service
metadata:
  name: order-service
spec:
  selector:
    app: order-service
    version: blue    # ← switch this to "green" for cutover
  ports:
    - port: 80
      targetPort: 8080

Traffic cutover and rollback

Deploy green, run smoke tests, then patch the Service selector for an instant cutover. Rollback is reversing the patch.

Shell — cutover and rollback commands

# 1. Deploy green (does not receive traffic yet)
kubectl apply -f order-service-green.yaml

# 2. Smoke test green using internal DNS or port-forward
kubectl port-forward deployment/order-service-green 8081:8080
curl http://localhost:8081/actuator/health

# 3. Cutover: patch Service selector to green
kubectl patch service order-service   -p '{"spec":{"selector":{"version":"green"}}}'

# 4. Watch for errors (1-5 minutes)
kubectl get events --field-selector type=Warning

# 5a. SUCCESS: scale down blue
kubectl scale deployment order-service-blue --replicas=0

# 5b. ROLLBACK: revert selector back to blue (instant)
kubectl patch service order-service   -p '{"spec":{"selector":{"version":"blue"}}}'

# Automate with ArgoCD application health gates
# argocd app sync order-service --strategy=basic

Database schema considerations

The hardest problem in blue-green: if blue and green run different schema versions, both must be compatible with the same database. Use expand-contract (parallel writes) pattern.

SQL — expand-contract schema migration pattern

# Expand-Contract (aka parallel change) pattern for schema migrations:

# Phase 1 — EXPAND (backwards-compatible migration):
# Add new column with nullable or default (old code ignores it, new code writes it)
ALTER TABLE orders ADD COLUMN reference_id VARCHAR(50) NULL;

# Deploy GREEN (writes both old + new columns)
# Blue and Green run simultaneously, both compatible

# Phase 2 — CONTRACT (after green is stable, blue is removed):
# Make column NOT NULL now that all data is populated
ALTER TABLE orders MODIFY COLUMN reference_id VARCHAR(50) NOT NULL;

# Remove old column (after all green, no more blue)
ALTER TABLE orders DROP COLUMN old_reference;

# Key rule: NEVER run a migration in the same deployment that:
# 1. Adds a NOT NULL column without default (breaks blue)
# 2. Drops a column still read by blue code
# 3. Renames a column (both blue and green reference different names)

Key Points to Remember

1Blue-green provides instant rollback by switching the load-balancer/Service selector — no gradual traffic shifting.
2Both environments must remain compatible with the same database schema during the transition window.
3Use the expand-contract pattern for schema changes: add new columns first, deploy, then remove old columns later.
4Cold-start latency: warm up green (health checks, cache population) before cutting over to avoid error spikes.
5Blue-green costs 2× infrastructure; use deployment slots (Azure) or Kubernetes inactive Deployments to manage cost.
6Blue-green is better than canary for large atomic changes that cannot be partial (e.g. dependent service contracts).

Interview Questions

What is the main difference between blue-green and canary deployment strategies?

EasyNetflix

How do you handle database schema changes during a blue-green deployment?

HardUber

What is the expand-contract pattern and why is it necessary for zero-downtime migrations?

HardAmazon

How would you implement blue-green in Kubernetes without a service mesh?

MediumGoogle

What happens to in-flight requests during a blue-green cutover and how do you handle them?

MediumShopify

Ask Aria about Blue-Green Deployment

Your personal AI tutor — ask anything about this concept

Revision Status

Personal Notes

Discussion

Loading discussion…

Kubernetes for Microservices

Canary Deployment