Deployment Strategies Matrix

Rolling, canary, blue-green. When each.

Rolling deploy

Replace pods or instances one at a time. Default in Kubernetes Deployments and most ASG configurations. Simple, low cost, well-understood.

Trade-off: limited rollback speed. If a regression hits, the rollback rolls in reverse. Mid-rollout state can be mixed; both versions serving simultaneously.

Best for: routine deploys of stateless services with backwards-compatible changes. The default unless you have a reason to choose otherwise.

Canary deploy

Gradual ramp from small percentage of traffic to full. 5%, 25%, 50%, 100%. Each stage gates on health metrics.

Catches regressions before they reach all customers. The first 5% surfaces the most issues; subsequent stages confirm.

Best for: high-stakes changes (database connection logic, payment paths, ML model swaps). Tools: Argo Rollouts, Flagger, vendor canary support.

Blue-green deploy

Two full environments. Blue is current production; green is the new version. Traffic flips atomically from blue to green.

Fastest rollback: flip back. Both versions stay deployed during the cutover; rollback is instant.

Cost: double infrastructure during the cutover window. For zero-downtime migrations and high-stakes deploys, the cost is justified.

Shadow deploy (dark launch)

New version processes a copy of production traffic without serving responses to users. Behaviour observed; users unaffected.

Catches issues that only appear under real load and traffic shape. Synthetic load testing misses these.

Higher operational complexity: traffic mirroring, separate observability for shadow, eventual cutover plan. Worth it for risky changes.

Picking the right strategy

Routine, backwards-compatible: rolling. The default, lowest-cost.

High-stakes change with metric-driven gates: canary. The middle ground; most production-grade.

Zero-downtime requirement, atomic cutover: blue-green. Higher cost, fastest rollback.

Risky with hard-to-test edge cases: shadow first, then canary.