Comparison questionMedium~7 min

Interview question

How do you choose between rolling, blue-green, and canary deployment for a production API?

Choose rolling, blue-green, or canary deployment

Chooses a deployment strategy from capacity, compatibility, risk, observability, and rollback needs, then defines progressive promotion and abort signals.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

A rolling deployment replaces instances in batches and uses less duplicate capacity, but old and new versions overlap. Blue-green keeps two complete environments and switches traffic after validating the new one, which makes cutover and fallback fast at higher cost. A canary sends a small share of production traffic to the new version, observes it, and expands exposure in stages. I would choose based on change risk, traffic-routing capability, spare capacity, session behavior, and whether both application versions can safely use the same data and dependencies.

Full answer below

Practice focus

Deployment strategy, traffic shifting, capacity, compatibility, health signals, automated promotion, rollback, data changes, and cost.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
The strategies reduce release risk in different ways. A useful choice accounts for infrastructure capacity, version overlap, traffic control, state changes, and how quickly the team can detect a bad release.
A rolling deployment replaces instances in batches and uses less duplicate capacity, but old and new versions overlap. Blue-green keeps two complete environments and switches traffic after validating the new one, which makes cutover and fallback fast at higher cost. A canary sends a small share of production traffic to the new version, observes it, and expands exposure in stages. I would choose based on change risk, traffic-routing capability, spare capacity, session behavior, and whether both application versions can safely use the same data and dependencies.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
Whichever strategy I use, promotion needs explicit health gates such as error rate, latency, saturation, business failures, and critical-flow checks. Database and event changes remain backward compatible while versions overlap, often through expand and contract. Sticky sessions, background consumers, scheduled jobs, and caches need separate treatment because traffic weights do not control all work. Feature flags can separate code deployment from user exposure, but they do not replace infrastructure health or cleanup.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I would roll out by low-risk cohort, instance group, availability zone, or region when the platform supports it, with bounded observation windows and an automatic pause or abort. Rollback is straightforward only when the release has not produced incompatible data or irreversible external effects; otherwise roll-forward or feature disablement may be safer. The pipeline records which artifact, configuration, migration state, and cohort are active at each stage. I would also test the fallback path, reserve enough capacity for it, and remove old environments and temporary routing rules after the release stabilizes.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Choosing blue-green and forgetting the cost of two production-capable environments.
Calling a deployment canary without controlling or measuring its traffic cohort.
Ignoring old and new version compatibility during a rolling release.
Using infrastructure success as the only promotion signal.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

The rollout advances even when business-error or latency signals regress.
Background workers from both versions process the same jobs incompatibly.
Rollback depends on a database state the old version can no longer read.
No one knows which users, regions, or instances received the canary.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When is a rolling deployment safer than blue-green?
Which signals would automatically stop a canary?
How do database changes affect rollback?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.