In this article
Before you start
Why interviewers ask this
A release is the moment most outages start, so the question tests whether you can ship a change without taking the service down or hurting everyone at once. It arrives as "how would you deploy this service?" at the end of a system design round, or as a scenario about a release that went wrong. A weak answer names one tool and stops.
A strong answer names the options, says what each one costs in capacity and risk, and says how the release is judged healthy and how it is undone. This page gives that vocabulary, the arithmetic behind it and an answer you can say aloud. The round itself is described in the system design guide, and the whole loop in how interview loops work.
Deployment strategies from first principles
- Deployment strategy
- A deployment strategy is a plan for moving a running service from an old version to a new one that fixes how traffic and instances change over time, and therefore how much downtime, extra capacity and risk the release carries.
- Rolling update
- A rolling update is a deployment strategy that replaces old instances with new ones in small batches, so that old and new versions serve traffic together until the last old instance is gone.
- Blue-green deployment
- A blue-green deployment is a deployment strategy that keeps two production environments, one live and one idle, and switches all traffic from the live one to the idle one once the new version has been checked.
In plain words
Think of changing the engine of a bus while it carries passengers. You can stop the bus, swap the engine and restart (recreate). You can swap one seat-row of bolts at a time while it keeps moving (rolling). You can keep a second, identical bus waiting and move the passengers over in one go (blue-green).
Or you can put a few brave passengers on a test bus first and watch how they get on (canary). The analogy breaks at the data: a bus has no database that both engines must share, and in software the shared data is the hardest part of every strategy. In one precise sentence: a strategy is a rule about how much traffic each version gets, and when.
Step 1: Recreate, stop the old version and start the new one
Recreate is the strategy that stops every old instance before it starts any new one, so the service is unavailable in between. The Kubernetes documentation states it plainly: with the Recreate type, all existing Pods are killed before new ones are created (read October 2026). It needs no extra capacity and never runs two versions at once, which makes it the only safe choice when two versions must not share a database or a lock. The price is the gap: for the length of the restart, no instance answers. You now know the baseline that every other strategy improves on: the cost of one step is downtime and full exposure.
Step 2: Rolling update, replace instances in small batches
A rolling update replaces instances a few at a time, so some old instances always keep serving. In Kubernetes the batch size is set by two limits: maxSurge, the number of extra instances allowed above the desired count, and maxUnavailable, the number that may be missing. Both default to 25%, and a percentage is rounded up for surge and down for unavailable (Kubernetes documentation).
For ten instances that means at most 3 extra and at least 8 serving at every moment. The rollout needs about 30% spare capacity at peak and never drops below 80% of normal.1 Old and new versions answer requests together, so both must tolerate the same data. A rollout stops being safe when the bad version looks healthy at first.
Step 3: Blue-green, switch between two full environments
Blue-green deployment keeps two production environments that are, in Fowler's words, "as identical as possible": one serves users while the other receives the new version and its final checks (Fowler, 1 March 2010). When the checks pass, a router moves all traffic to the new environment. Rollback is the same switch in reverse, because the old environment is still running; the Amazon Web Services (AWS) whitepaper of 29 September 2021 lists downtime and rollback as the risks it reduces. The cost is capacity: two full environments, so peak capacity is 200% of normal during the switch.1 The catch is the database, which both colours usually share.
Step 4: Canary, send a small share of traffic first
A canary release sends a small share of live traffic to the new version and keeps the rest on the old one as the control. Fowler describes it as a technique to reduce the risk of a new version by routing a small group of users first and rerouting them back if problems appear (Fowler, 25 June 2014).
The Google Site Reliability Engineering (SRE) Workbook defines canarying as a partial, time-limited deployment of a change and its evaluation, and its worked example uses a 5% canary (Google SRE Workbook, chapter 16). In our model a release that fails 2% of its requests reaches an alarm in 30 seconds at a 5% share and ends with 150 failed requests, against 2,430 for a full cutover.1 The share is the control knob.
Step-by-step description
- All old stop, nothing serves, then all new start.
- Batches: 3 new added, 2 old removed, peak 13, minimum 8.
- Test the idle environment, then flip the router.
- 5% on the new version beside a 95% control.
- Recreate leaves zero instances serving between the old and new versions.
- A rolling update adds 3 new instances, peaks at 13 and never has fewer than 8 available.
- Blue-green flips all traffic between two environments with a router.
- A 5% canary runs beside a 95% control and is compared before it is widened.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Worked example
Take ten identical instances serving 1,000 requests a second, and a new version that fails 2% of the requests it serves. The inputs below are illustrative; the arithmetic is computed, not typed.1 The first table is the capacity each strategy needs, using the Kubernetes defaults for the rolling update.
| Strategy | Peak capacity | Lowest serving capacity | Rollback |
|---|---|---|---|
| Recreate | 100% | 0% during the restart | redeploy the old version |
| Rolling update (10 instances, defaults) | 130% | 80% | roll forward or back, batch by batch |
| Blue-green | 200% | 100% | switch the router back |
| Canary (5% of 20 instances) | 105% | 100% | send the share back to the old version |
The second table adds the exposure. Assume, as an illustration, that an alarm fires after 30 failed requests are seen and a rollback then takes 120 seconds (illustrative) with the share frozen. A cutover to everyone fails 2,430 requests, because 20 requests a second fail and the alarm takes 1.5 seconds. A rolling update that ramps over five minutes fails 270. A 5% canary fails 150, and a 1% canary fails 54, although it needs 150 seconds to reach the alarm.
| First share of traffic | Seconds to alarm | Failed requests until rollback |
|---|---|---|
| 100% in one step | 1.5 | 2,430 |
| Rolling ramp over 300 seconds | 30 | 270 |
| 5% canary | 30 | 150 |
| 1% canary | 150 | 54 |
Text description of the diagram
- A full cutover fails 20 requests a second and 2,430 in total.
- A 5% canary fails 1 request a second and 150 in total.
Recap of the model: In that model a full cutover fails 20 requests a second and 2,430 in total, while a 5% canary fails 1 request a second and 150 in total.1 A 5% canary runs beside a 95% control and is compared before it is widened.
Recreate leaves zero instances serving between the old and new versions, and a rolling update adds 3 new instances, peaks at 13 and never has fewer than 8 available. The reading: capacity and blast radius pull in opposite directions. The blast radius is the share of users a single bad change can hurt. Blue-green gives the cleanest rollback but exposes everyone at the switch; a canary limits exposure but needs a version-by-version comparison of health.
Trade-offs and edge cases
The strategies are not exclusive: teams often run a canary first and finish with a rolling update. The same ideas apply to releasing a model, covered in the machine learning operations (MLOps) guide and the machine learning (ML) system design guide, and a canary is only as good as the signals behind it, which observability for large language model (LLM) services discusses. Two edge cases decide most real choices, and three neighbouring techniques are easy to confuse with the four strategies.
Shadow deployments, A/B tests and feature flags. These are not replacement strategies; they answer different questions. A shadow (dark) deployment runs the new code on real traffic without users seeing its results; Fowler describes dark launching as done "to assess the additional load and performance impacts upon the system" (Fowler, 29 April 2020). An A/B test compares user behaviour between variants to learn which one is better, not whether the release is safe; Hodgson files it under "Experiment Toggles" (Hodgson on martinfowler.com, revised 9 October 2017).
A feature flag, in the same article, is "allowing teams to modify system behavior without changing code", so a feature can ship switched off and be enabled later without a new deploy. A canary asks "is this build healthy?"; a shadow run asks "can it take the load?"; an A/B test asks "do users prefer it?".
Shared data. Blue-green and rolling updates both put two versions in front of one database. Fowler's advice is to deploy schema changes separately from application upgrades: make a backward-compatible change first, verify it, then ship the application (Fowler, 2010). A change that cannot be made backward compatible is the case for recreate, with its downtime.
A canary that is too small or too short. The SRE Workbook says a canary must be big enough to be representative: ending one after a handful of queries gives no useful signal. It also warns that an off-peak canary can miss defects that appear only under heavy load, and advises running one canary at a time (Google SRE Workbook). The 1% row above shows the trade: less exposure, a slower answer.
Text description of the diagram
- Accept downtime only where two versions cannot coexist.
- Pay for a second environment where fast rollback matters most.
- Choose a canary where per-version health can be measured.
- Otherwise a rolling update is the default.
Read the flow from the first question down. Accept downtime only where two versions cannot coexist. Pay for a second environment where fast rollback matters most. Choose a canary where per-version health can be measured. Otherwise a rolling update is the default. The wider DevOps and cloud interview guide places these strategies beside the rest of the delivery toolchain.
How to answer it in an interview
How would you deploy a new version of this service with no downtime and a way back?
I would start with a rolling update, because it needs only a little spare capacity and keeps old instances serving. Before it widens, I would send a small canary share, about five percent, and compare error rate and latency against the old version. If the comparison is bad I send the share back. If rollback speed matters more than cost, I use blue-green and accept double capacity. Whichever I choose, I check how the database change behaves with both versions running, because that is where releases usually break.
The spoken structure is: the options, the cost of each, the health check, then the data caveat.
Common mistakes
"Blue-green means no risk." (wrong) Everyone moves to the new version together, so a bad release hits every user at once. (right) "Blue-green gives a fast rollback, not a small blast radius."
"A canary and a rolling update are the same." (wrong) A rolling update replaces everything as it goes and may not compare versions. (right) "A canary holds a small share fixed and compares it with a control before widening."
"Rollback is just redeploying the old code." (wrong) Data written by the new version may not work for the old one. (right) "Plan the rollback with the data change, not after it."
"A canary's traffic share is always its instance share." (wrong) That holds only under equal-weight balancing, which is the Kubernetes Service case: one Service selects both tracks and, in the documentation's words, you "tweak the number of replicas of the stable and canary releases to determine the ratio of each release that will receive live production traffic" (Kubernetes workload management, last modified 7 July 2026). One canary beside ten stable instances therefore gets about 9%. Weighted routing, such as a service mesh, a weighted load balancer or weights in the Kubernetes Gateway application programming interface (API), sets the share independently of instance count. (right) "Say whether you control the share by instance count or by routing weight."
Follow-up questions
What is the difference between blue-green and canary deployment?
Blue-green switches all traffic between two full environments after checks, so it rolls back fast but exposes everyone. A canary shifts a small share of traffic first and compares versions, so it limits exposure but needs measurement.
What happens when the new version needs a database change?
Split the change in two: ship a backward-compatible schema first, verify it, then ship the application, as Fowler advises. Both versions must work against the same data while they overlap.
What should you watch during a canary?
Watch a small set of health signals for the canary and the control together, such as error rate and slow-request share. The SRE Workbook suggests perhaps no more than a dozen metrics and metric intervals no longer than the canary.
How is a canary different from A/B testing or a shadow deployment?
A canary sends real users to the new build to check it is healthy and withdraws it if not. A shadow deployment copies traffic to the new build without showing users its output, so it tests load and behaviour at no user risk. An A/B test splits users to compare behaviour and pick a winner, and is usually driven by a feature flag.
How is a rolling update different from a canary release?
A rolling update steps through every instance until none is old. A canary holds a small share on the new version, evaluates it and only then widens it.
What if you cannot afford double the capacity?
Use a rolling update with a small surge or a canary. Both add only a few percent to 30% extra capacity in the worked example, against 100% for blue-green.
- Recreate stops everything, needs no spare capacity and is safe when two versions cannot coexist.
- A rolling update with Kubernetes defaults needs 130% peak capacity for ten instances and never drops below 80%.
- Blue-green gives the fastest rollback for 200% peak capacity and exposes everyone at the switch.
- A 5% canary failed 150 requests in the model against 2,430 for a full cutover.
- Whatever the strategy, plan the database change and the rollback together.
Sources
- Deployments (Kubernetes documentation) — The Kubernetes Authors, 7 Jul 2026
- BlueGreenDeployment — Martin Fowler, 1 Mar 2010
- CanaryRelease — Martin Fowler, 25 Jun 2014
- Blue/Green Deployments on AWS (whitepaper) — Amazon Web Services, 29 Sep 2021
- Workload Management (Kubernetes documentation) — The Kubernetes Authors, 7 Jul 2026
- DarkLaunching — Martin Fowler, 29 Apr 2020
- Feature Toggles (aka Feature Flags) — Pete Hodgson, martinfowler.com, 9 Oct 2017
- Canarying Releases (The Site Reliability Workbook, chapter 16) — Google, 1 Jul 2018
