Blue-green deployment prepares a new application version in a separate environment while the previous version serves traffic. After readiness checks, routing directs new work toward the new environment. Keeping the old environment available can shorten rollback, because recovery need not wait for another build. The pattern does not make every dependency duplicated, every switch instantaneous, or every data change reversible.

The article’s in-memory model updates two routers separately. Existing sessions remain blue after new routes become green. An additive schema supports both versions; replacing a required field makes blue incompatible. Real cutover needs separate routing, capacity and data evidence.
Routing selection and state compatibility are distinct. The model explains overlap and schema limits; it is not a measured router rollout or a guarantee of safe recovery.

Define what the switch controls

The routing mechanism might be a load-balancer backend, a service selector, or DNS. Each has different propagation and connection semantics. Updating one control-plane object does not imply that all data-plane instances change at the same instant. DNS caches and existing connections can continue using old destinations after the authoritative configuration changes.

Decide whether routing applies per request, connection, session, or queued job. A persistent connection can remain on blue while new connections reach green. Some proxies select an upstream for each request instead. The longest-lived client connection alone therefore does not define every drain window. Document the actual mechanism and its timeout and termination behavior.

Both versions should support their assigned traffic and dependencies. That does not require identical software versions or permanently paying exactly twice the total system cost. Capacity can be staged, and databases or supporting services may be shared. Savings have consequences: an old environment scaled down too far may no longer provide a quick, full-capacity rollback target.

Keep data compatible across the overlap

A shared database is common, but is a design choice rather than the definition of blue-green. Separate databases introduce replication, synchronization, and reconciliation questions. A routing reversal cannot erase writes already accepted by green or safely invent transactions missing from blue. Define what happens to data as carefully as what happens to requests.

With a shared store, expand-and-contract changes keep both versions working during overlap. Add compatible fields, deploy readers and writers that tolerate both representations, backfill where needed, and only later remove obsolete structure. Waiting for old HTTP connections to end is insufficient if old workers, scheduled jobs, rollback binaries, or external consumers still need the old schema.

Check semantic compatibility as well as column names. Both versions might parse a field while interpreting its units differently. A migration can cause rejected queries, inconsistent writes, or later corruption; corruption is not inevitable, but neither is a clean error. Exercise realistic read and write paths and validate representative business results before declaring rollback safe.

When it breaks

Mixed-version responses during cutover are not automatically a deployment failure. They may be the expected result of draining, gradual propagation, or intentional traffic splitting. They become a problem when clients or shared state cannot tolerate that overlap. Include release identity in useful diagnostics, then correlate failures with routing state, connection age, and application compatibility.

Conversely, fifty responses from one client all reporting green do not prove global atomicity. That client may repeatedly hit one edge or reuse one connection. Readiness replica counts also do not establish that a service selector, endpoint list, ingress controller, or external load balancer points at those replicas. Inspect the complete path and test representative client locations.

Finally, do not retire blue merely because the switch command succeeded. Define a rollback window, monitor error and latency changes, and confirm old workers have stopped before incompatible cleanup. If rollback depends on state that has already changed irreversibly, choose a forward repair or a rehearsed data-recovery procedure instead of repeatedly flipping the route.

Check it quickly

Run the following Python 3 model with assertions enabled. It changes only in-memory dictionaries. Two routers update separately, existing sessions retain their selected environment, and a schema contract determines whether either version can run. This is an explicit model, not a measured load-balancer rollout or a Kubernetes integration test.

routers = {"edge-a": "blue", "edge-b": "blue"}
existing = {"session-1": "blue", "session-2": "blue"}
routers["edge-a"] = "green"
assert set(routers.values()) == {"blue", "green"}
routers["edge-b"] = "green"
assert set(routers.values()) == {"green"}
assert set(existing.values()) == {"blue"}
print("new routes green; existing sessions still blue")

required = {"blue": {"amount_cents"}, "green": {"amount_cents", "currency"}}
def compatible(schema, colour):
    return required[colour] <= schema
schema = {"amount_cents", "currency"}
assert all(compatible(schema, colour) for colour in required)
routers = dict.fromkeys(routers, "blue")
assert compatible(schema, "blue")
print("rollback remains schema-compatible")

# A destructive replacement can invalidate the old version.
required["green"] = {"amount_minor", "currency"}
schema = {"amount_minor", "currency"}
assert compatible(schema, "green")
assert not compatible(schema, "blue")
print("routing rollback cannot restore a removed column")

The first assertion exposes a mixed routing state. Even after both routers select green, the modeled sessions remain blue. The additive schema supports a routing rollback; the later destructive replacement does not. The three output lines identify those boundaries without inventing a universal cutover duration.

Repeat these checks in an isolated deployment using the real router, representative traffic, and reversible test data. Measure propagation, draining, and rollback separately. Preserve evidence of both routing convergence and compatible application behavior; neither substitutes for the other.

Sources