Once deployments stop involving downtime, two strategies dominate. Blue-green runs two complete environments and switches traffic from one to the other in a single move. Canary sends a small share of traffic to the new version, watches, and increases gradually. They sound like variations on a theme and behave quite differently under failure.
Blue-green's appeal is the rollback: traffic switches back in seconds, because the old environment is still running and untouched. Its weakness is that the switch is all or nothing, so a problem that only appears under real production load hits every user at once. You find out fast and you fix it fast, but everyone saw it.
Canary inverts that. One per cent of users meet the new version first, so a serious defect affects a hundredth of your traffic while you decide. The cost is that both versions run simultaneously for a period, which means they must be mutually compatible - same database schema, same message formats, same cache keys. Every deployment becomes a compatibility exercise.
That compatibility requirement is usually what decides it, and it is a database question rather than an infrastructure one. If your release includes a schema change that the old version cannot tolerate, canary is unavailable to you - you cannot run both against one database. This is why expand-migrate-contract migrations and progressive deployment go together: the migration discipline is what makes the deployment strategy possible.
Canary is also only as good as what you watch during the rollout, and the mistake is watching the aggregate. If ninety-nine per cent of traffic is healthy and one per cent is erroring badly, the overall error rate barely moves. You need metrics segmented by version - error rate, latency, and at least one business signal such as checkout completions - or the canary is just a slower way to deploy everything.
For most teams the pragmatic answer is both, at different layers. Blue-green or rolling deployment for the infrastructure, because it is simple and the rollback is genuinely fast. Feature flags for the behavioural change on top, which gives you canary-style progressive exposure at the level of individual features without requiring two versions of the whole application to coexist. That combination gets you most of the benefit for considerably less operational complexity.
