You release a risky change to a service used by millions. How do you deploy it?

Use a canary: deploy next to the old version, send a small share of traffic, watch error rate and latency, then increase in steps and roll back automatically if a threshold is crossed. Pair it with a feature flag for the risky behaviour. The trade-off is slower rollout and the need for good metrics.

What are the benefits and costs of blue-green deployment?

A full new environment is ready and tested before traffic switches, and switching back is instant. The costs are double capacity during the release, and shared state: both versions usually use the same database, so migrations still need to be compatible. The trade-off is speed of rollback against infrastructure cost.

A release needs a database column renamed. How do you avoid downtime and a broken rollback?

Use expand and contract. Add the new column, deploy code that writes both and reads the old, backfill, switch reads to the new column, deploy code that no longer touches the old column, and only then remove it in a later release. At every step the previous version of the code still works. The trade-off is several releases for one change.

Your canary looked fine, but the full release failed under load. Why, and what could you do?

A small share of traffic may never trigger problems that depend on volume, such as lock contention or connection limits. Raise traffic in more steps with pauses, run load tests, or use shadow traffic to test at full volume without affecting users. The trade-off is time and cost against confidence.

What is the difference between deploying and releasing, and why does it matter?

Deploying puts code on servers, and releasing makes users see the change. Feature flags let you deploy with the feature off and release it gradually, and switch it off in seconds without a new deployment. The trade-off is flag management: old flags must be removed.

You roll back a release, but users still see errors. What could be wrong?

Switching traffic back does not undo data. If the new version wrote rows or messages in a new format, the old version may not read them. Check version skew during a partial rollout, incompatible database changes, and caches that hold new-format data. Keep changes backward compatible and use expand and contract so the old version works at every step. The trade-off is more releases and slower cleanup against a rollback you can trust.

Deployment Strategies | TheLearningLoop

Why deployment strategy matters, and when to choose which

Shipping new code is widely reported as one of the most common causes of outages (a common pattern, not a figure measured here). A deployment strategy is the plan for moving users from the old version to the new one so a bad release hurts as few people as possible and can be undone quickly.

It gives you two things interviewers always ask about:

Availability: users keep getting service while the release happens, with no downtime window.
Safety: a bad change is caught early, affects few users, and can be rolled back fast.

Use a gradual strategy when:

The service is user-facing and downtime or errors cost money or trust.
You release often, so each release must be low risk.
You can measure health (error rate, latency) to decide whether to continue.

Keep it simple (all at once) when:

The service is internal, low traffic or has a quiet maintenance window.
A rollout takes seconds and failure is cheap.
The change is a tiny, well-tested configuration.

Try it

Release a new version using one of four strategies. Choose one of three kinds of release: a good one, a bad one, or one whose bug only shows at full traffic.

Deployment Strategies

Step 1 of 7 · Press Space to play, arrow keys to step

StrategyRelease

Initial state. Version 1 serves everyone. A new version 2 is about to be released.

tick:: 0
users hit by errors:: 0
new version share (%):: 0
detected at tick:: -

1 tick = one step of the simulation.

Speed

Things to try:

Run All at once with a bad release. Everyone gets the bug, and fixing it is slow.
Compare Rolling and Canary. A canary shows the problem to a small share first.
Choose a release whose bug only shows at full traffic and see why a small canary is not enough. Then try Blue-green to see the instant rollback.

What to watch: the counter users hit by errors at the end of each run. The numbers are illustrative, not measurements: the simulation assumes 1,000 users per tick at full traffic, that the problem is noticed straight away, and that undoing the release takes 3 ticks for all at once, 2 for rolling, 1 for canary and 0 for blue-green. With these assumptions:

Strategy	Bad release	Bug only at full traffic
All at once	4,000	4,000
Rolling	750	3,000
Canary	100	2,000
Blue-green	1,000	1,000

Read the table with care. A canary limits how many users a visible bug reaches, but it cannot see a bug that needs volume. Blue-green does not limit who sees the bug, because it switches everyone at once; it only makes the way back instant. In the real world, noticing a problem also takes time, which the simulation leaves out. In the simulation the canary jumps from 5% straight to everyone, whereas the safe rollout below raises the share in several steps.

Deployment strategies

Strategy	How it works	Good when	Weakness
All at once (recreate)	Stop the old version, start the new one everywhere	Internal tools, maintenance windows	Downtime or a risky switch, slow rollback
Rolling	Replace servers a few at a time	Default for stateless services	Old and new versions run together, rollback is another rollout
Canary	Send a small share of traffic to the new version, then increase	Risky changes, large audiences	Needs good metrics and traffic splitting (a router that sends a chosen share of requests to each version)
Blue-green	Run a full new copy beside the old, switch traffic over	Instant rollback, big releases	Double the capacity during the switch
Feature flags	Ship code turned off, enable it for chosen users	Separate deploy from release, gradual exposure	Flags need cleanup, and add branches
Shadow (dark launch)	Copy real traffic to the new version without using its answers	Testing performance and correctness safely	Adds load (up to double if all traffic is copied), and must not cause side effects

Releasing code vs releasing a feature

Deploying puts a new build on servers. Releasing makes users see the change.
With feature flags, you deploy the code switched off, then release it to 1%, 10% and everyone by changing a setting, and switch it off again in seconds if it misbehaves.
This separates the risk of a bad build from the risk of a bad feature, and it removes the need to redeploy to roll back.

How a safe rollout works

Build once and promote. The exact artifact that passed tests goes to production.
Deploy to a small group (a canary, or a few servers). Run health checks first (a readiness check is a request the new server must answer correctly), and do not send traffic until they pass.
Compare metrics (errors, latency, saturation meaning how close a resource is to its limit, and business numbers such as orders per minute) between the new and old versions over enough time and traffic.
Increase gradually if healthy: for example 5%, 25%, 50%, 100%.
Roll back automatically if a metric crosses a threshold, by shifting traffic back or turning off the flag.
Handle data carefully. Make database changes backward compatible (add a column, deploy code, then remove the old one later) so the old and new code can both run. Before the old column is removed, release code that no longer reads or writes it, so nothing still depends on it when it goes.

Strategy design vs the alternatives

Concern	Canary or blue-green	Rolling	All at once
Users hit by a bad release	Few with a canary, but all of them with a plain blue-green switch	Some	All
Speed of rollback	Fast	Medium	Slow
Extra capacity needed	Some or double	Little	None
Complexity	High	Medium	Low
Needs good metrics	Yes	Helpful	No
Best for	Critical services	Most services	Small or internal

Blue-green is about how fast you can undo a release, not about how many users see it. If you want both, send a small share to the new stack first, then switch.

Pick the lightest strategy that matches the cost of a failure.

Avoiding a new single point of failure

The traffic switch (load balancer, router or mesh) is now critical. Run it redundantly and test failover.
The deploy pipeline should be reliable and have a manual, documented path for emergencies.
Feature flag service: cache flag values locally and use safe defaults if it is down.
Shared data: old and new versions often share one database, so migrations are the real risk. Keep them reversible.
Rollback has limits. If the new version already wrote data in a new format, switching traffic back does not undo that data. While a rollout is partial, old and new versions run together, so they must understand each other's messages and data. When you switch away from a server, let in-flight requests finish (connection draining) before stopping it.

You accept extra capacity, more tooling and the discipline of backward-compatible changes.

Common mistakes

No health checks before traffic. New servers receive requests before they are ready.
Releasing database changes that break the old version. Rollback then fails.
Canary with too little traffic or time. Rare errors are invisible. For example (illustrative numbers), at 1,000 requests per second a 5% canary sees 50 requests per second, or 3,000 per minute. A bug that fails 1 request in 1,000 then shows up only about 3 times a minute, which is hard to tell from normal noise.
No automatic rollback. People notice late.
Flags that never get removed. Old branches pile up.
Deploying on Friday evening without a plan. Keep releases small and frequent.

How to talk about deployment in an interview

Start with the goal: no downtime and a fast way back.
Describe a rolling or canary release with health checks and metrics, and blue-green when instant rollback matters.
Mention feature flags to separate deploy from release, and backward-compatible database migrations.
Name the trade-off: safer releases cost extra capacity, tooling and process.

Where you meet deployment strategies in real systems

Every company that ships often uses a mix of these. Here are three drawn out, the first with configuration you can run, then more examples.

Example 1: Rolling updates and a canary split

Kubernetes rolls out a new version a few pods at a time. If the new pods never pass their readiness check, the rollout stalls and the old pods keep serving, but Kubernetes does not undo the release by itself. You, or a tool such as Argo Rollouts, must roll back. NGINX can send a small share of traffic to a new version. Open the example below to see the picture and the configuration.

Config: rolling update and a 5% canarySetup 1 manifest and 1 configCode no code changes

Five per cent of traffic goes to the new version. If its errors stay low, the share is raised in steps. If they rise, traffic goes back to the old version at once.

# A Deployment that replaces pods a few at a time. Names and the image are placeholders.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  selector:
    matchLabels:
      app: web
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1      # at most 1 old pod may be down at a time
      maxSurge: 1            # at most 1 extra new pod may be created at a time
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: example.com/web:2.0.0
          readinessProbe:      # a new pod gets traffic only after this check passes
            httpGet:
              path: /healthz
              port: 8080
            periodSeconds: 5

The NGINX file passed nginx -t on the official image. The Kubernetes manifest was checked with kubectl apply --dry-run=client. Names, images and addresses are examples. The NGINX split works on the client address, not on each request, so a client always sees the same version, but the share of requests may differ from 5% if some clients send much more traffic than others, and clients behind one shared address move together. The config only splits traffic; watching metrics and moving the share is a separate job.

Example 2: Blue-green

Two full environments exist. Traffic points at one, and a switch moves it to the other.

The router sends all traffic to green. Blue still runs the old version, so switching back is one change if the new version misbehaves.

Example 3: Compatible database changes

The database change goes in steps, so both versions of the code work at every step.

Add the new column first, deploy code that writes both, move the data, switch reads, then remove the old column in a later release.

In practice, stop using the old column in a release of its own before you remove it. Only then is the removal safe for every version that might still run.

More real-world scenarios

The scenarios below are typical patterns, not claims about named companies.

4. Web and mobile back ends

Servers are updated by rolling releases with health checks. Mobile apps depend on old API versions, so changes stay compatible.

5. Feature launches

A new checkout is turned on for employees, then 1% of users, then everyone, by changing a flag.

6. Large retailers on peak days

Teams freeze risky changes and rely on canaries and instant rollback for the changes they must make.

7. Search and ranking changes

A new ranking runs in shadow mode, and its results are compared with the live ones before anyone sees them.

8. Infrastructure changes

Operating system or configuration changes are rolled through a small group of hosts first.

9. Machine learning models

A new model serves a small share of requests, and its quality metrics decide whether it replaces the old one.

10. Database migrations

Schema changes are made in expand and contract steps so the application can be released and rolled back freely.

Tools and managed services

Kind	Name	Notes
Orchestrator	Kubernetes Deployments	Rolling updates with readiness checks
Progressive delivery	Argo Rollouts, Flagger	Canary and blue-green with automatic analysis
Traffic splitting	NGINX, Envoy, Istio	Weighted routing between versions
Feature flags	LaunchDarkly, Unleash, OpenFeature	Control exposure without redeploying. OpenFeature is a vendor-neutral API and SDK for reading flags, used with a flag provider, not a flag service itself
Managed	AWS CodeDeploy, Google Cloud Deploy	Hosted rollout pipelines

The takeaway

Whenever a release could hurt users, expose it to a small share first, watch real metrics, and keep a one-step way back.

Deployment Strategies

Key takeaways

Why deployment strategy matters, and when to choose which

Try it

Deployment Strategies

Deployment strategies

Releasing code vs releasing a feature

How a safe rollout works

Strategy design vs the alternatives

Avoiding a new single point of failure

Common mistakes

How to talk about deployment in an interview

Where you meet deployment strategies in real systems

Example 1: Rolling updates and a canary split

Example 2: Blue-green

Example 3: Compatible database changes

More real-world scenarios

4. Web and mobile back ends

5. Feature launches

6. Large retailers on peak days

7. Search and ranking changes

8. Infrastructure changes

9. Machine learning models

10. Database migrations

Tools and managed services

The takeaway

Interview questions