Deployment Strategies Diagram: Rolling, Blue-Green and Canary

Most outages start with a deploy. The code passed review and tests, and then it met real traffic, real data and real dependencies. A deployment strategy decides how much of your traffic meets the new version at once, how quickly you notice a problem, and how fast you can undo it.

This post compares the three strategies most teams choose between: rolling updates, blue-green and canary releases. It shows how traffic moves in each, what rollback looks like, and ends with a diagram of a canary release where the decision to continue or roll back is automated.

Rolling update

Replace instances of the old version with the new one a few at a time. Kubernetes Deployments do this by default: with the RollingUpdate strategy, maxSurge and maxUnavailable control how many extra and missing pods are allowed during the rollout, and both default to 25%.

• Traffic: during the rollout, both versions serve requests at the same time, in proportion to how many pods each has.
• Rollback: another rolling update back to the old version. Minutes, not seconds.
• Cost: almost nothing extra; at most the surge capacity.
• Risk: every user can hit the new version early, and readiness probes are the only automatic gate. A version that starts fine but fails under load gets fully rolled out.

Rolling updates are the right default for low-risk changes and internal services with good tests and probes. Make the readiness probe check what the service needs to work, not just that the process is up, or the rollout will happily replace healthy pods with broken ones.

Blue-green

Run two complete environments. Blue serves production; green gets the new version and is tested in place. Then the load balancer or DNS switches all traffic from blue to green at once. Martin Fowler's description of blue-green deployment is the classic reference.

• Traffic: all on blue, then all on green. Never both, at least not for long.
• Rollback: switch back to blue, which is still running. Seconds.
• Cost: double capacity while both are up.
• Risk: the switch moves 100% of users at once, so a problem that only appears under real traffic hits everyone. The database is shared, so schema changes must work with both versions.

Canary

Send a small share of real traffic, say 5%, to the new version, compare it with the stable version, and widen the share in steps if it behaves. The name comes from the canary in the coal mine; see the canary release article on Fowler's site.

• Traffic: split by weight, by header or by user segment.
• Rollback: set the canary's weight to zero. Seconds, and only a few percent of users were exposed.
• Cost: a few extra pods, plus the tooling for traffic splitting and analysis.
• Risk: lowest of the three, if you watch the right metrics. A canary nobody watches is a slow rolling update.

Side by side

The last row is the same everywhere for a reason: in every strategy, two versions of the code meet the same database at some point. Use expand-and-contract migrations: add new columns and tables first, deploy code that works with both shapes, and remove the old shape in a later release.

Shadow traffic before the canary

Some teams add a step before the canary: copy a share of production requests to the new version and throw its responses away. Envoy and Istio can mirror traffic this way. It catches crashes and latency regressions with no user impact at all, but only for reads and idempotent requests. Mirrored writes repeat their side effects, such as emails, payments and inventory changes, so keep them out of the mirror or point the shadow at sandboxed dependencies.

Automating the canary decision

The value of a canary comes from the comparison, and people are bad at watching dashboards for an hour. Tools such as Argo Rollouts and Flagger automate it on Kubernetes: they shift traffic in steps, query your metrics provider between steps, and promote or abort based on thresholds you define.

Good analysis metrics are few and close to the user:

• Error rate (5xx responses) of the canary, compared with stable.
• Latency at a high percentile, such as p99.
• One business signal where possible, such as checkouts completed per minute.

Compare canary against stable, not against a fixed number, so a bad night for a dependency does not fail every release.

The architecture diagram

How to read it:

• Top, the traffic path: users reach the ingress, which sends 95% of requests to the stable ReplicaSet and 5% to the canary. Both report to metrics.
• Bottom, the control loop: CI hands the new image to the rollout controller. The controller sets the ingress weights (dashed edge), reads error rate and p99 latency for both versions, and decides.
• The decision: within thresholds, move to the next step; outside them, abort and send all traffic back to v1.
• The Markdown block lists the steps and the abort rule, which belong in the review of every service's rollout config.

Feature flags are the fourth strategy

A deployment strategy controls which servers run new code. A feature flag controls which users see a new behavior, independent of deploys. Teams that ship often combine them: deploy with a rolling update or canary, keep risky features behind a flag, and turn the flag on gradually. The flag is the faster rollback, because nothing has to be redeployed.

What to put on a deployment diagram

• Traffic percentages on the edges. They change during a rollout; show the first step.
• Who changes the weights. A controller, a pipeline or a person.
• The abort criteria. Numbers, not "if it looks bad".
• The database, and a note that schema changes are expand-and-contract.

The CI/CD pipeline diagram shows the build and test stages that come before this, the Kubernetes architecture diagram covers the cluster, and the observability architecture diagram shows where the metrics come from.

Build it in Archboard

1. Sign in with Google or GitHub and create a diagram.
2. Add a Person for users and an Ingress and two ReplicaSet nodes from the Kubernetes pack for stable and canary.
3. Add Metrics and a Pipeline from the DevOps pack, and a Container from the C4 Model pack for the rollout controller.
4. Add a Decision, a Process and a Terminator from the Flowchart pack for promote and abort.
5. Label the ingress edges with traffic weights, draw the weight changes as a dashed edge, and add a Markdown block from the Core pack with the steps.

The example uses 11 diagram nodes, within the Free plan.

FAQ

Which deployment strategy is best? It depends on risk and tooling. Rolling updates suit most low-risk changes; canaries suit user-facing services where a bad release is expensive; blue-green suits systems that need instant, complete switches and can afford double capacity.

What is the difference between blue-green and canary? Blue-green switches all traffic at once and keeps the old environment for instant rollback. A canary moves a small share of traffic first and widens it only when the new version proves itself.

How do I handle database migrations during a deploy? Make every schema change backward compatible: expand first, deploy code that works with both shapes, then contract in a later release.

What metrics should a canary analysis use? Error rate and high-percentile latency compared with the stable version, plus one business metric if you can measure it quickly.

Are feature flags a deployment strategy? They are a release strategy. They decouple turning a feature on from deploying the code, and combine well with any of the three deployment strategies.

Start free — one seat, no credit card.