Canary Deployment: Mermaid Flowchart Diagram

About Source

A canary deployment gradually shifts a small percentage of production traffic to a new version of a service, monitoring metrics and error rates before incrementally increasing the rollout — allowing teams to catch regressions with minimal blast radius.

What the diagram shows

The diagram begins with the Load Balancer routing all traffic to v1.0 Stable (100%). When a new release is ready, the canary phase starts: the load balancer is reconfigured to send 5% of traffic to v2.0 Canary while 95% remains on v1.0. A Monitoring & Metrics gate continuously evaluates error rates, latency percentiles, and business KPIs for the canary cohort.

If metrics are healthy after an observation window (e.g. 30 minutes), traffic is increased incrementally — 5% → 25% → 50% → 100%. At each step, the monitoring gate re-evaluates. If any step shows degraded metrics, Rollback returns all traffic to v1.0 immediately. Once 100% has shifted successfully, v1.0 instances are decommissioned.

Why this matters

Canary deployments limit the impact of a bad release to only the percentage of users in the canary cohort. If a bug only manifests under specific real-world conditions, a 5% canary exposes it to real users while protecting the other 95%. Unlike Blue Green Deployment, canary doesn't require two full environments running simultaneously, reducing infrastructure cost. The trade-off is complexity in managing multiple live versions and ensuring the monitoring pipeline is reliable enough to make promotion decisions automatically.

Frequently asked questions

A canary deployment is a release strategy that gradually shifts a small percentage of production traffic to a new version, monitoring error rates and latency before incrementally increasing the rollout — named after the "canary in a coal mine" signal for detecting problems early.

The load balancer is configured to route a small traffic slice (typically 5%) to the new version while the remainder stays on the stable version. A monitoring gate evaluates the canary's health metrics over an observation window. If metrics are healthy, the percentage is increased in steps; if degraded, all traffic rolls back to the stable version.

Use canary deployments when you want to validate a new release under real production traffic with limited blast radius, especially when changes affect latency-sensitive paths or when your team wants automatic, metric-driven promotion rather than a manual approval step.

Common mistakes are using too small an initial traffic slice to gather statistically significant signal, relying on insufficient metrics (only HTTP 5xx, ignoring latency percentiles or business KPIs), and promoting too quickly — not allowing enough time for slow-burn issues to surface.

mermaid

flowchart TD
    LB[Load Balancer] -->|95% traffic| V1[v1.0 Stable\nProduction]
    LB -->|5% traffic| V2[v2.0 Canary]
    V2 --> Monitor[Monitoring & Metrics\nError Rate / Latency / KPIs]
    Monitor -->|Metrics healthy| Increase[Increase canary traffic\n5% → 25% → 50% → 100%]
    Monitor -->|Metrics degraded| Rollback[Rollback to 100% v1.0]
    Increase --> FullRollout{100% shifted\nto v2.0?}
    FullRollout -->|Yes| Decommission[Decommission v1.0]
    FullRollout -->|No| Monitor