Overview
A deployment strategy determines how a new version replaces the old one in production. The goal is to release with zero downtime and limit the impact of bad releases. Common strategies are recreate (stop old, start new), rolling (replace instances gradually), blue-green (switch traffic between two full environments), canary (send a small percentage of traffic to the new version first), and feature flags (deploy code dark and enable it separately).
Safe deployments also depend on backward-compatible changes: database migrations must work with both old and new code (expand and contract), APIs must stay compatible, and rollbacks must be fast and tested.
Recreate is closing the old bridge before the new one opens. Rolling replaces one lane at a time. Blue-green builds a second bridge and switches all traffic at once. Canary lets a few cars try the new bridge first and watches for problems.
When to use it
- Every production release.
- High-traffic services where bad releases are costly.
- Risky changes that need gradual exposure.
- Decoupling deployment from release with flags.
Where it shows up in interviews
Recognize it when: deploy without affecting users.
- Design deployments for a payments API
- Design release process for a mobile backend
Recognize it when: limit blast radius of a bad release.
- Design progressive delivery
- Design a safe schema migration
Where it is used in real software
Automate canary and blue-green on Kubernetes with metric-based promotion and rollback.
LaunchDarkly, Unleash, and in-house systems let companies deploy continuously and release features gradually.
Supports canary and linear traffic shifting for Lambda and ECS.
Key terms
- Rolling update
- Replace instances in batches.
- Blue-green
- Two environments; switch traffic instantly.
- Canary
- Small percentage of traffic to the new version first.
- Feature flag
- Runtime toggle for code paths.
- Expand and contract
- Migrate schemas in backward-compatible steps.
How it works, step by step
- 1Make the change backward compatible
Old and new versions must coexist.
- 2Deploy to a small slice
Canary pods or a subset of hosts.
- 3Compare metrics
Error rate, latency, business KPIs vs baseline.
- 4Promote gradually
5% to 25% to 50% to 100%.
- 5Roll back automatically
If metrics degrade beyond thresholds.
Strategies compared
Pick by risk and cost
| Strategy | Downtime | Rollback speed | Extra cost | Risk exposure |
|---|---|---|---|---|
| Recreate | Yes | Slow (redeploy) | None | All users at once |
| Rolling | No | Medium | Small surge capacity | Grows batch by batch |
| Blue-green | No | Instant (switch back) | 2x environment | All users at switch |
| Canary | No | Fast | Small | Small percentage first |
| Feature flags | No | Instant (toggle) | Flag system | Chosen users/segments |
NOWStrategy: Recreate | Downtime: Yes | Rollback speed: Slow (redeploy) | Extra cost: None | Risk exposure: All users at once
Canary with automated analysis plus feature flags is the modern default for high-traffic services.
Implementation
apiVersion: argoproj.io/v1alpha1kind: Rolloutmetadata: { name: api }spec: replicas: 10 selector: { matchLabels: { app: api } } template: metadata: { labels: { app: api } } spec: containers: - name: api image: containers.artifactory.tools.bestbuy.com/team/api:def5678 strategy: canary: steps: - setWeight: 5 - pause: { duration: 10m } - analysis: { templates: [{ templateName: error-rate-below-1pct }] } - setWeight: 25 - pause: { duration: 10m } - setWeight: 50 - pause: { duration: 10m } # then 100% automaticallyComplexity and performance
Two full environments.
Needs enough traffic for statistics.
Trade-offs
More canary steps catch more issues but slow releases.
Flags decouple release from deploy but accumulate technical debt if not removed.
Variants and related techniques
Mirror production traffic to the new version without returning its responses.
Canary-like routing for product experiments with user segments.
Common mistakes
- Breaking schema changes deployed with code.
Fix: Use expand and contract; old pods still run during rollouts.
- Canary without metrics.
Fix: Automate analysis on error rate and latency, not just 'pods are running'.
- Stale feature flags.
Fix: Track and remove flags after full rollout.
Interview questions
Canary vs blue-green?
Blue-green runs two full environments and switches all traffic at once, offering instant rollback at double cost. Canary shifts a small percentage of traffic to the new version and increases it gradually based on metrics, limiting the blast radius.
How do you deploy a database schema change with zero downtime?
Expand and contract: add new structures compatible with old code, deploy code that writes both, backfill, switch reads, and remove old structures only after no old code runs.
Practice problems
| Problem | Difficulty | What it trains |
|---|---|---|
| Plan a canary for a payment API | Medium | Metrics and steps. |
| Rename a column with zero downtime | Medium | Expand and contract. |