Deployment Strategies
Overview
Deployment strategies are the techniques for shipping a new version of a service without taking it down or risking a bad release on all users at once. The main patterns - rolling, blue-green, canary - differ in how they shift traffic from old to new, and feature flags decouple "deployed" from "released" so you can turn behavior on and off independently of the binary.
Key Concepts
Rolling deployment replaces instances in batches: take down a few, upgrade them, add them back, repeat. No extra fleet is needed, but old and new versions run simultaneously during the roll, so they must be compatible.
Blue-green deployment runs two full environments. "Blue" serves production while "green" gets the new version; you flip the load balancer to green in one step, and roll back instantly by flipping back. It costs double the infrastructure during the switch.
Canary deployment routes a small slice of traffic (say 1%) to the new version, watches error rate and latency, and only then ramps to 100% - automatically rolling back if metrics degrade.
Feature flags separate deployment from release: the code ships dark, and a runtime toggle enables it for chosen users. This enables trunk-based development, A/B tests, and instant "kill switches" without a redeploy.
| Strategy | Extra capacity | Rollback speed | Blast radius during rollout |
|---|---|---|---|
| Rolling | None | Slow (roll back) | Gradual |
| Blue-green | ~2x (temporary) | Instant (flip) | All-or-nothing at switch |
| Canary | Small | Fast (shift traffic) | Tiny (small % first) |
| Feature flag | None | Instant (toggle) | Controlled per cohort |
Safe rollout depends directly on observability - you cannot canary what you cannot measure - and pairs with resilience patterns so a bad deploy degrades gracefully instead of cascading.
Trade-offs
Rolling is cheapest but couples you to backward compatibility and rolls back slowly. Blue-green gives the fastest, cleanest rollback but doubles cost during the switch and makes stateful data migrations tricky (both environments may touch the same database). Canary minimizes blast radius and is the safest for risky changes, but it requires solid metrics and automation to be worth the added pipeline complexity. Feature flags are powerful but accumulate as technical debt: stale flags left in code become a maintenance and testing burden.
Interview Tips
- Default to "canary with automatic rollback on error-rate/latency regression" for risky changes.
- Use blue-green when you need instant, clean rollback and can afford the temporary double capacity.
- Separate "deploy" from "release" with feature flags, and mention flag cleanup to avoid debt.
- For schema changes, describe backward-compatible, multi-step migrations (expand/contract) so old and new versions coexist.
Summary
- Deployment strategies control the risk of shipping new versions without downtime.
- Rolling upgrades in batches (cheap, needs version compatibility); blue-green flips between two full environments (instant rollback, double cost).
- Canary sends a small traffic slice to the new version and ramps only if metrics stay healthy.
- Feature flags decouple deploy from release, enabling dark launches, A/B tests, and kill switches.
- Safe rollout requires strong observability; clean up stale flags and use expand/contract for schema changes.