Skip to content
Optimal Lab

System design · interactive

Deployment strategies

Version 2 has a bug that fails 30% of requests. You don't know that yet. How many users get hurt depends on how you roll it out. Ten instances, 1,000 requests per step.

  1. step 11 instance (10%) gets v2 · 30 failed
  2. step 2canary error rate 30% vs 0.1% baseline · 30 failed
  3. step 3automatic rollback
  4. step 4
  5. step 5
  6. step 6
v1 v2 (buggy)

60 failed requests in total

Only 10% of traffic sees v2. Its error rate is compared with the old version and it's rolled back automatically: 60 failed requests.

Strategy

Step 3 of 4

  1. 1

    Rolling: replace a few at a time

    No extra servers needed, and Kubernetes does it by default. But old and new run side by side, and a bug spreads gradually.

    maxSurge: 25% · maxUnavailable: 0

  2. 2

    Blue-green: flip all traffic

    Warm up a complete copy, switch the router, keep the old one for instant rollback. Costs double capacity during the switch.

    Database changes still need care.

  3. 3

    Canary: a small slice first

    Send a few percent of traffic to the new version, compare error rate and latency with the old, then widen or roll back automatically.

    Argo Rollouts and Flagger automate the analysis.

  4. 4

    Feature flags

    Ship the code switched off and turn it on per user or percentage. Rolling back is flipping a flag.

    Make database migrations backwards-compatible first.

In production

Tools and technologies

Deploy tooling automates these rollouts.

Not tied to one language — use these names when you search docs or design a system.