Canary, Blue-Green & Rollouts

Deployment strategies

Strategy	Downtime	Risk	Cost
Rolling	None (if backward compatible)	Mixed versions live	Low
Blue-green	Switch instant	2× resources during cutover	Medium
Canary	None	Limited blast radius	Medium
Recreate	Brief outage	Simple, brutal	Low

Canary rollout (staff default)

1. Deploy v2 alongside v1
2. Shift 1% → 5% → 25% → 100% traffic (Service Mesh or gateway weights)
3. Monitor error rate, latency SLO, business metrics
4. Auto-rollback on burn rate alert (Observability → SLOs)

Blue-green

Two identical environments; flip router from blue to green. Fast rollback = flip back.

Challenge: state — DB migrations must work for both versions or use expand-contract pattern.

Feature flags vs traffic canary

	Feature flag	Traffic canary
Unit	Code path	Request percentage
Use	Hide incomplete features	Validate new binary
Risk	Flag debt, wrong evaluation	Infra complexity

Use both: flag guards new logic; canary validates performance.

Schema coupling

Expand-contract migrations:

1. Add new column (expand)
2. Dual-write or backfill
3. Switch readers
4. Remove old column (contract)

Never deploy breaking schema + code atomically across services.

Database per service implication

Each service migrates its own DB independently — no shared migration tool across monolith tables.

Cross-reference: Communication for API versioning during rollout.