Blue-Green vs Canary Deployments

Understand the two traffic models

In blue-green delivery, blue may serve production while green receives the new release and verification. A router, load balancer, or service mapping then sends normal traffic to green. Blue remains available for a short recovery window. The model is conceptually simple but temporarily requires duplicate capacity and a trustworthy switch.

A canary sends a limited portion of real traffic to a new version while the previous version continues serving the rest. Exposure can be percentage-based, identity-based, geographic, or tied to internal users. Canary steps provide comparative evidence but require reliable traffic splitting, enough events for evaluation, and careful interpretation when user groups differ.

Choose from workload constraints

Blue-green suits services that can duplicate their serving environment and benefit from a quick route reversal. Canary suits high-volume services where gradual evidence can reveal errors before full exposure. Low-volume systems may wait too long for a statistically useful canary, while expensive stateful stacks may make full duplicate environments impractical.

Review sessions, long-lived connections, background jobs, scheduled tasks, and consumers. Running both versions may duplicate work if each starts the same scheduler. Sticky sessions can bias traffic and complicate comparisons. Define whether rollback means only routing requests or also stopping workers and reconciling events created by the new version.

Preserve state compatibility

Application versions often share a database during rollout. Use backward-compatible schema expansion first: add nullable fields or new structures, deploy code that tolerates both forms, migrate data, and remove old structures in a later release. A route rollback cannot undo an incompatible schema deletion or reverse externally visible side effects.

Version messages and APIs so old and new consumers understand overlapping formats. Keep caches namespaced when serialized data changes. For changes with irreversible effects, use a feature flag or shadow calculation before enabling mutation. Document the point after which traffic rollback is no longer enough and specialist recovery is required.

Use evidence to advance or stop

Define step duration, traffic amount, minimum sample, and indicators before deployment. Watch errors, latency, saturation, dependency failures, and a critical business outcome such as successful checkout. Compare canary and baseline under similar conditions. Avoid advancing only because no alert fired; confirm the telemetry pipeline and release marker are present.

Automate pause and rollback for clear severe thresholds, while retaining human judgment for ambiguous signals. Test the traffic switch with a harmless prior version in a controlled environment. After success, remove old capacity deliberately, preserve evidence, and review whether the chosen strategy found issues early enough to justify its complexity.

Canary a checkout calculation change

A retailer is changing discount calculation code that reads the same database and can affect order totals.

1. Deploy the new calculation in shadow mode and compare its proposed totals with the existing version without changing customer orders.
2. Resolve expected differences, then expose the new version to internal accounts with a route that prevents duplicate background processing.
3. Advance through small traffic steps while comparing calculation errors, checkout success, latency, and manual discrepancy reviews.
4. Pause or route traffic back immediately on a defined incorrect-total threshold, preserving requests and version evidence for diagnosis.

Progressive release plan

Approve this plan before creating the new serving version.

• Strategy choice, workload rationale, duplicate capacity, traffic mechanism, and session behavior.
• Version overlap for database, messages, caches, files, APIs, workers, and scheduled tasks.
• Exposure steps, duration, sample requirement, comparison baseline, and responsible approver.
• Errors, latency, saturation, business indicators, telemetry check, and numeric stop conditions.
• Traffic rollback, side-effect recovery, old-capacity retention, completion checks, and evidence record.

Common mistakes

• Calling a rolling replacement a canary without measuring a distinct limited traffic group.
• Planning route rollback while deploying a database change that old code cannot read.
• Advancing exposure because dashboards are quiet without checking that canary telemetry is labeled and arriving.

Try one

Sources

• Amazon EC2 Auto Scaling documentationOfficial AWS guidance for maintaining and adjusting groups of compute instances.
• Kubernetes Deployments documentationOfficial Kubernetes guidance for declarative application rollout, scaling, and revision management.