Target Group for Blue Environment

and Smoke Testing:** Run automated integration tests and health checks against the new environment. This must include database connectivity and downstream dependency checks. 4. Traffic Switch: Atomically update the router or load balancer to direct traffic to the new environment. 5. Post-Deployment Monitoring: Monitor metrics on the new active environment. If anomalies occur, trigger an immediate rollback by switching traffic back. 6. Resource Management: The old environment becomes the standby for the next cycle. Scale down resources if cost optimization is required, or keep them warm for instant rollback capability.

Architecture Decisions

Database Compatibility: The most critical architectural constraint is database schema management. Blue-green deployments require backward-compatible database changes. The new application version must work with the existing schema, and the old version must work with the new schema during the transition. This necessitates the "Expand/Contract" pattern:

• Expand: Add new columns/tables without removing old ones.
• Deploy: Switch traffic to the new version.
• Contract: In a subsequent release, remove deprecated schema elements.

Stateless Design: Blue-green is most effective with stateless applications. If sessions or caches are stored locally, user requests routed to the new environment may lose context. Externalizing state to Redis, DynamoDB, or similar services is mandatory for seamless switching.

Code Examples

The following TypeScript implementation demonstrates a robust traffic switch controller with pre-switch validation. This script ensures traffic is only switched if health checks and critical metrics pass.

import axios from 'axios';

interface EnvironmentConfig {
  name: 'blue' | 'green';
  url: string;
  healthEndpoint: string;
}

interface SwitchResult {
  success: boolean;
  message: string;
  timestamp: Date;
}

class BlueGreenController {
  private activeEnv: EnvironmentConfig;
  private standbyEnv: EnvironmentConfig;
  private router: LoadBalancerRouter;

  constructor(active: EnvironmentConfig, standby: EnvironmentConfig, router: LoadBalancerRouter) {
    this.activeEnv = active;
    this.standbyEnv = standby;
    this.router = router;
  }

  async deployAndSwitch(newVersion: string): Promise<SwitchResult> {
    console.log(`Deploying ${newVersion} to ${this.standbyEnv.name}...`);
    
    // 1. Deploy artifact to standby environment
    await this.deployArtifact(this.standbyEnv, newVersion);

    // 2. Validate readiness
    const isValid = await this.validateEnvironment(this.standbyEnv);
    if (!isValid) {
      return {
        success: false,
        message: 'Validation failed for standby environment. Deployment halted.',
        timestamp: new Date()
      };
    }

    // 3. Atomic traffic switch
    try {
      await this.router.switchTraffic(this.standbyEnv.name);
      const previousActive = this.activeEnv;
      this.activeEnv = this.standbyEnv;
      this.standbyEnv = previousActive;

      console.log(`Traffic switched to ${this.activeEnv.name}.`);
      return {
        success: true,
        message: `Successfully switched traffic to ${this.activeEnv.name}`,
        timestamp: new Date()
      };
    } catch (error) {
      // Rollback immediately if switch fails
      console.error('Traffic switch failed. Initiating rollback.');
      await this.router.switchTraffic(this.activeEnv.name);
      throw new Error('Critical failure during traffic switch. Rollback executed.');
    }
  }

  private async validateEnvironment(env: EnvironmentConfig): Promise<boolean> {
    // Health check
    const healthCheck = await axios.get(`${env.url}${env.healthEndpoint}`);
    if (healthCheck.status !== 200) return false;

    // Smoke test against critical paths
    const smokeTests = [
      this.verifyDatabaseConnectivity(env.url),
      this.verifyCacheWarming(env.url)
    ];

    const results = await Promise.allSettled(smokeTests);
    return results.every(r => r.status === 'fulfilled');
  }

  private async verifyDatabaseConnectivity(url: string): Promise<void> {
    const response = await axios.get(`${url}/internal/db-check`);
    if (response.data.status !== 'connected') {
      throw new Error('Database connectivity check failed');
    }
  }

  private async verifyCacheWarming(url: string): Promise<void> {
    // Logic to ensure cache is populated to acceptable levels
    const metrics = await axios.get(`${url}/metrics/cache-hit-ratio`);
    if (metrics.data.hitRatio < 0.85) {
      throw new Error('Cache hit ratio below threshold');
    }
  }
}

Kubernetes Service Configuration: The traffic switch in Kubernetes is achieved by updating the selector of the Service resource. This is an atomic operation handled by the API server.

apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  selector:
    app: my-app
    version: green  # Toggle between 'blue' and 'green' labels
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

Pitfall Guide

1. Non-Backward-Compatible Database Changes

Mistake: Dropping a column or changing a data type in the new version while the old version is still running. Impact: When traffic switches, the old environment (now standby) cannot be used for rollback because the schema has changed. If the new version fails, you cannot switch back without data loss or errors. Best Practice: Enforce expand/contract migrations. Never remove schema elements in the same release as the code change. Use feature flags to gate new database access paths.

2. Stateful Session Loss

Mistake: Storing user sessions in local memory or on ephemeral storage within the container. Impact: Users active during the traffic switch lose their session state, resulting in forced logouts or cart abandonment. Best Practice: Externalize all session state to a distributed cache or database. Ensure the application is truly stateless regarding user context.

3. Cold Start Latency on Standby

Mistake: Scaling down the standby environment to zero or minimal resources to save costs. Impact: When deployment occurs, the new environment experiences cold starts, causing high latency for the first wave of traffic after the switch. Best Practice: Keep the standby environment warm with minimum replica counts. Use pre-warming scripts to initialize caches and connections before declaring the environment ready.

4. Configuration Drift

Mistake: Manual configuration changes applied to the active environment that are not propagated to the standby. Impact: The standby environment becomes stale. When activated, it lacks critical configuration, leading to immediate failure. Best Practice: Treat configuration as code. Use Infrastructure as Code (IaC) and configuration management tools to ensure both environments are identical. Implement drift detection in the CI/CD pipeline.

5. DNS Caching Delays

Mistake: Relying on DNS changes for traffic routing without accounting for TTL (Time To Live). Impact: Users continue to hit the old environment due to cached DNS records, causing split-brain scenarios where users see different versions simultaneously. Best Practice: Use load balancers or service meshes for traffic switching instead of DNS. If DNS must be used, reduce TTL values well in advance of the deployment window.

6. External Dependency Versioning

Mistake: Assuming downstream services are stable and backward compatible. Impact: The new version calls a downstream API that has changed, or the downstream service is not ready for the new traffic pattern. Best Practice: Implement contract testing with downstream dependencies. Use circuit breakers and retries. Coordinate releases with dependent teams when API contracts change.

7. Cost Oversight

Mistake: Deploying blue-green without calculating the infrastructure overhead. Impact: Unexpected budget overruns, especially in cloud environments where resources are billed per hour. Best Practice: Automate resource scaling. Keep standby environments at minimum viable capacity. Use spot instances for standby if fault tolerance allows. Monitor costs continuously and set alerts for dual-environment spend.

Production Bundle

Action Checklist

• Validate Database Compatibility: Ensure all schema changes are backward-compatible and follow the expand/contract pattern.
• Implement Atomic Traffic Switching: Configure load balancer or service mesh to support instant selector updates with no connection drops.
• Automate Pre-Switch Validation: Script health checks, smoke tests, and metric thresholds that must pass before traffic switch is allowed.
• Externalize State Management: Verify all user sessions, caches, and temporary data are stored in external, shared services.
• Define Rollback Triggers: Configure automated monitoring alerts that trigger immediate traffic reversion if error rates or latency spike post-switch.
• Audit Configuration Parity: Implement drift detection to ensure active and standby environments remain identical in configuration.
• Optimize Standby Costs: Set minimum resource quotas for the standby environment and automate scaling based on deployment schedules.

Decision Matrix

Scenario	Recommended Approach	Why	Cost Impact
High-Risk Financial Transaction Service	Blue-Green	Instant rollback minimizes financial exposure and ensures data consistency.	High (2x infra)
Cost-Sensitive Internal Tool	Rolling Update	Lower infrastructure cost; downtime risk is acceptable for internal users.	Low
User-Facing Feature with A/B Testing Needs	Canary	Allows gradual traffic shift and metric comparison before full rollout.	Low
Stateful Database Migration	Rolling / Expand-Contract	Blue-green cannot handle non-compatible schema changes safely.	Medium
Regulatory Compliance Requirements	Blue-Green	Audit trails for deployment versions and instant rollback capability are easier to demonstrate.	High

Configuration Template

Terraform + AWS ALB Pattern: This template demonstrates the infrastructure setup for blue-green using AWS Application Load Balancer and Target Groups.

resource "aws_lb" "app" {
  name               = "app-lb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.lb.id]
  subnets            = var.public_subnets
}

# Target Group for Blue Environment
resource "aws_lb_target_group" "blue" {
  name     = "app-blue"
  port     = 8080
  protocol = "HTTP"
  vpc_id   = var.vpc_id

  health_check {
    path                = "/health"
    interval            = 30
    healthy_threshold   = 3
    unhealthy_threshold = 3
  }
}

# Target Group for Green Environment
resource "aws_lb_target_group" "green" {
  name     = "app-green"
  port     = 8080
  protocol = "HTTP"
  vpc_id   = var.vpc_id

  health_check {
    path                = "/health"
    interval            = 30
    healthy_threshold   = 3
    unhealthy_threshold = 3
  }
}

# Listener Rule with Weighted Forwarding
resource "aws_lb_listener_rule" "traffic_switch" {
  listener_arn = aws_lb_listener.frontend.arn
  priority     = 100

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.blue.arn
    
    # Weights control traffic distribution
    # Set blue_weight to 100 and green_weight to 0 for Blue active
    # Toggle weights to switch traffic
    forward {
      target_group {
        arn     = aws_lb_target_group.blue.arn
        weight  = var.blue_weight
      }
      target_group {
        arn     = aws_lb_target_group.green.arn
        weight  = var.green_weight
      }
    }
  }
}

Quick Start Guide

1. Provision Dual Environments: Create two identical deployment targets (e.g., Kubernetes namespaces blue and green, or EC2 Auto Scaling Groups). Ensure they share the same database and external services.
2. Deploy Initial Version: Deploy version 1.0 to the Blue environment. Configure the load balancer to route 100% of traffic to Blue. Verify service health.
3. Deploy New Version: Deploy version 2.0 to the Green environment. Do not switch traffic yet. Run automated integration tests against the Green endpoint.
4. Validate and Switch: Execute the validation script. If all checks pass, update the load balancer configuration to route 100% of traffic to Green. In Kubernetes, update the Service selector label.
5. Monitor and Confirm: Observe metrics on the Green environment for 15 minutes. If stable, mark Blue as the standby environment for the next cycle. If issues arise, revert the load balancer to Blue immediately.