Blue-Green Deployment: Traffic Switching and State Compatibility

Blue-green deployment: a traffic switch is only part of rollback

Blue-green deployment keeps two application environments: one serving production traffic and one prepared for the next release. After validation, routing moves to the new environment. Keeping the previous environment available can make recovery faster, provided its data and external contracts remain compatible. AWS's deployment whitepaper describes the general technique and operational considerations. Blue/Green Deployments on AWS.

The colors are labels, not separate guarantees. A routing change can propagate gradually; open connections may continue using the previous version. Database writes and external side effects do not disappear when traffic switches back.

Capacity before cutover

Assume peak traffic is 300 requests per second and a representative test shows one instance meeting the chosen latency objective at 80 requests per second. Four instances provide 320 requests per second of tested capacity, leaving little headroom. Five provide 400 and can lose one while retaining 320. Those numbers are example test inputs, not a general server benchmark.

During overlap, five blue and five green instances may each open 20 database connections: 200 total. A database configured for 150 application connections can fail before green receives any customer traffic. Budget shared dependencies, background consumers, caches, and connection pools alongside application servers.

Green should run the same immutable build artifact validated earlier. Warm essential caches and verify configuration, migrations, and access to dependencies without unintentionally sending real emails or executing scheduled billing twice.

What actually switches?

In a Kubernetes illustration, a Service can select the active deployment's pod labels:

apiVersion: v1
kind: Service
metadata:
  name: catalogue
spec:
  selector:
    app: catalogue
    track: blue
  ports:
    - name: http
      port: 80
      targetPort: 8080

A green deployment would use app: catalogue and track: green. Changing the selector selects a different endpoint set. This Service fragment is not a complete deployment: readiness checks, replicas, resources, routing, and access policies still need configuration. Kubernetes documents selector-based Services and endpoint management. Kubernetes Services.

Do not assume all existing connections jump to green. Allow blue to drain in-flight requests and long-lived connections under a defined timeout. Requests that are retried during the transition need normal idempotency protections. DNS switching has different caching and propagation behavior from an application load-balancer update.

Make the database compatible in both directions

Suppose blue reads and writes name, while green is intended to use full_name. Renaming the column just before the switch makes blue unusable for rollback.

Use a staged migration:

1. Add the new column without removing the old one.
2. Deploy a compatibility release that keeps both representations synchronized on every relevant write.
3. Backfill existing rows in bounded batches and verify agreement.
4. Deploy green so it can read the new representation while preserving the old contract during the rollback window.
5. Remove the old representation only after the rollback window closes and all readers and writers have migrated.

The compatibility release matters: if blue keeps updating only name, a backfill can become stale immediately. Triggers, application dual writes, or another migration strategy each require their own concurrency and failure analysis. Not every data transformation is reversible, especially if information is discarded.

Event formats need the same care. A green producer sending a new required field or meaning to an old consumer can break processing even when HTTP traffic has rolled back. Version contracts and retain compatible consumers while both releases can be active.

Blue-green, canary and feature flags are different controls

Blue-green describes parallel environments and cutover. Canary describes exposing a subset of traffic to a new version. They can be combined, but neither implies the other. A rolling deployment replaces instances incrementally; a feature flag controls behavior independently of which build is running.

For this release, route a small test cohort to green, verify a representative purchase or account flow, then perform the intended cutover. Select the observation duration from traffic volume and the failure being detected. Ten quiet minutes with three requests tells little about a rare error.

Establish the rollback window before release

Record the active build, configuration, schema compatibility, routing target, and the last point at which reversal remains safe. Watch error rates and latency by version, plus business completion and data-integrity signals. A global average can hide errors affecting only the green cohort.

A rollback drill should switch to green while requests are in progress, write data through green, and then return to blue. Verify that blue reads the new data correctly, retried requests do not duplicate actions, scheduled work runs once, and connections finish or fail in a controlled way. If any of those fail, “instant rollback” is an untested hope.

Retire blue when the agreed window and validation are complete. Keeping it forever increases cost and can leave a forgotten worker or outdated service active. The useful outcome is a measured recovery procedure with compatible state, not merely two server groups with different names.