The deployment pattern taxonomy — five patterns, four trade-off axes

A deployment pattern is the answer to a single question: how do old and new versions of a service coexist during the release? Five answers have survived in production: recreate, rolling update, blue-green, canary, and A/B. Each trades off availability, rollback speed, infrastructure cost, and blast radius against the others. Picking a pattern is not picking a favourite; it is matching the change’s data compatibility and risk tolerance to a point in the trade-off space.

The five patterns

flowchart LR
    A["Pattern taxonomy"] --> B["Recreate"]
    A --> C["Rolling update"]
    A --> D["Blue-green"]
    A --> E["Canary"]
    A --> F["A/B / shadow"]

• Recreate. The old version is stopped, then the new version is started. There is a window during which no version is serving traffic.
• Rolling update. The old version is replaced incrementally. Old and new coexist during the rollout, sharing the load.
• Blue-green. A second, identical environment is deployed with the new version. Traffic is switched at the load balancer from old (blue) to new (green) at a single moment.
• Canary. A small fraction of traffic is routed to the new version. If metrics hold, the fraction is increased in steps until the new version takes 100%.
• A/B / shadow. Traffic is split by user attribute (A/B) or mirrored to the new version without returning its responses (shadow). Used to compare behaviour or validate under real load without user impact.

The names are conventional but not universal; the tools (Argo Rollouts, Flagger, Spinnaker) sometimes use different terms for similar mechanics. Read the mechanics, not the name.

The four trade-off axes

Every pattern can be scored on the same four axes:

• Availability during rollout. Does traffic keep flowing, and does the user see errors?
• Rollback speed. How fast can the change be reverted when something goes wrong?
• Infrastructure cost. Does the pattern double the fleet, keep it the same, or temporarily exceed it?
• Blast radius. When the new version is broken, how many users see the break?

Recreate is cheapest on infrastructure and fastest on rollback (to the prior state) but produces the worst availability during the rollout. Blue-green is best on rollback (a single load balancer flip) but doubles the fleet. Canary is best on blast radius (1% of traffic first) but slowest to complete. Rolling update is the compromise: no fleet doubling, no full downtime, gradual rollout, and the new version must coexist with the old.

The hidden axis: data compatibility

The fifth constraint that does not appear in the trade-off matrix is data compatibility. Old and new versions of a service often share a database, a message queue, or a downstream API. The deployment pattern must allow that shared resource to be in a state both versions can read and write to during the rollout.

flowchart TD
    A["Pattern choice"] --> B["Traffic shape fits?"]
    A --> C["Data compatible?"]
    A --> D["Rollback simple?"]
    A --> E["Cost acceptable?"]

A blue-green deploy of a service that owns a database schema change is not safe: at the flip moment, the new version writes to a schema the old version cannot read. The pattern choice must account for the migration order, the dual-write window, and the schema’s backward compatibility. Rolling update and canary demand forward-and-backward compatibility during the coexistence window. Blue-green relaxes that constraint if the switch is atomic, but only if the database layer is shared.

Production discipline

1. Choose the pattern after the data migration is designed. Traffic shape is the second question, not the first.
2. Score every pattern on the same four axes. A pattern that scores well on availability but cannot roll back is a pattern that turns a routine incident into a long one.
3. Treat “we always use rolling update” as a smell. It is the default for stateless services and the wrong default for data-heavy services with breaking schemas.
4. Match the tool to the pattern. Kubernetes Deployment is rolling update and recreate only; Argo Rollouts and Flagger add canary and blue-green.

Cross-course references

• Kubernetes for Production Sysadmins - Parts XIV (Workloads) and XXII (Updates) cover the native Deployment rolling strategy and its limits.
• This course, Part LVII-04 (Pull request approvals) covers the change-side gate that runs before any of these patterns.
• This course, Part LVIII-02 through LVIII-05 cover the four common patterns in detail.

Quiz