Deployment Strategies Visualized

There's no universal deployment strategy let's understand the most common
deployment strategies.

Recreate (Big Bang)

This is the "turn it off and on again" of deployments. You stop all instances
of the old version, then start the new one. Yes, there's downtime. No, that's
not necessarily bad. If your users can tolerate a maintenance window, why
overcomplicate things?

Rolling Deployment

Instead of switching everything at once, you update instances one by one (or in
small batches). Traffic keeps flowing to healthy instances throughout the
process.

For a brief period, you'll have both v1 and v2 running simultaneously. If your
API and DB isn't backward compatible, you might have a bad time. You can
mitigate this by versioning you APIs and applying the expand and contract
pattern for DB migrations.

Blue-Green Deployment

This strategy keeps two identical environments: Blue (what's currently live)
and Green (the new version waiting in the wings). Once you've validated Green,
you flip the switch and all traffic moves over instantly.

The rollback is straightforward: Just point traffic back to Blue. Done. The
downside is you're paying for two environments.

Canary Deployment

Named after the canaries miners used to detect toxic gases, this strategy sends
a small percentage of traffic to the new version first. If those users don't
experience issues, you gradually increase the percentage.

You need solid metrics to know if that 5% of traffic is happy or not. Error
rates, latency percentiles, business metrics, pick your signals and watch them
closely.

Progressive Rollout

Think of this as canary deployments with autopilot. Instead of manually
deciding when to increase traffic, you define gates: "if error rate stays below
1% for 10 minutes, proceed to the next stage."

Choosing Your Strategy

The right deployment strategy depends entirely on your application's needs.
There's no one-size-fits-all answer, and you're not locked into a single
approach, these strategies can be mixed and matched.

Consider what matters most for your application:

• Can you tolerate downtime? Recreate deployments are simple and simplify version conflicts.
• Need zero downtime? Rolling, blue-green, canary, and progressive all keep your service available.
• How fast must you rollback? Blue-green offers instant rollbacks; rolling deployments take longer.
• Can you afford extra infrastructure? Blue-green doubles your resource cost; rolling uses about the same capacity.
• How mature is your monitoring? Canary and progressive require solid observability to be effective.
• What's your risk tolerance? Canary and progressive let you test with a subset of users first.

You can also combine strategies. For example, use rolling deployments for routine updates, but switch to canary for major changes. Or use blue-green for your API while doing rolling updates on your workers.