Rolling vs Blue-Green vs Canary Deployments: Which to Use When

Intermediate·3 min read·

Fast recall

Quick revision

Core answer

Rolling: replace pods/instances incrementally, default in K8s, cheapest, brief mixed-version state. Blue-green: stand up a parallel new environment and cut traffic over instantly, instant rollback but doubles capacity cost. Canary: route a small percentage of traffic (1–10%) to the new version, observe SLOs, then gradually expand. Use rolling for stateless backend services with backward-compatible changes, blue-green for atomic releases that can't tolerate mixed versions (database migrations, breaking API changes), canary for high-risk changes where you need real-traffic validation.

Interview Answer3 min

Three strategies, each trading something different to manage deployment risk.

Rolling — the default

Replace instances incrementally; new pod comes online, old pod drains and terminates; Kubernetes does this natively with maxSurge: 1, maxUnavailable: 0 for zero downtime
Cheapest — needs only ~25% extra capacity during the rollout; works perfectly for backward-compatible changes to stateless services
Trade-off: brief window where v1 and v2 both serve traffic; if your change isn't backward-compatible, this causes user-visible bugs

Blue-green — atomic cutover

Stand up the new version in a parallel environment ("green"); when ready, switch the load balancer from blue to green in one operation
Instant rollback by re-pointing the LB; no mixed-version state because all traffic goes to one environment
Cost: doubles infrastructure during the cutover window; for a 100-pod service that means 200 pods running simultaneously
Right choice for big-bang releases, breaking API changes, and library upgrades that don't tolerate mixed versions

Canary — progressive rollout

Route a small slice of production traffic (1%, then 5%, then 25%, then 100%) to the new version; observe error rates and latency at each step; auto-rollback on regression
Implemented with Argo Rollouts or Flagger driving traffic shifts via Istio or service mesh; metrics from Prometheus drive promotion decisions
Best for risky changes where you need real-traffic validation that pre-prod cannot provide — ML model updates, performance optimizations, new dependencies
Trade-off: slower (hours instead of minutes); requires service mesh or smart LB; needs solid SLO definitions to drive automated promotion

Practical guidance

Default to rolling for everyday changes; reach for canary on high-risk changes; reach for blue-green on atomic releases
Pair with feature flags to decouple deployment of binaries from rollout of features — makes the strategy choice less critical
Automate rollback: Argo Rollouts checking Prometheus rolls back faster and more reliably than humans staring at dashboards

Interview-ready guide

Interview answer

Three strategies, each trading something different to manage deployment risk.

Rolling — the default

Replace instances incrementally; new pod comes online, old pod drains and terminates; Kubernetes does this natively with maxSurge: 1, maxUnavailable: 0 for zero downtime
Cheapest — needs only ~25% extra capacity during the rollout; works perfectly for backward-compatible changes to stateless services
Trade-off: brief window where v1 and v2 both serve traffic; if your change isn't backward-compatible, this causes user-visible bugs

Blue-green — atomic cutover

Stand up the new version in a parallel environment ("green"); when ready, switch the load balancer from blue to green in one operation
Instant rollback by re-pointing the LB; no mixed-version state because all traffic goes to one environment
Cost: doubles infrastructure during the cutover window; for a 100-pod service that means 200 pods running simultaneously
Right choice for big-bang releases, breaking API changes, and library upgrades that don't tolerate mixed versions

Canary — progressive rollout

Route a small slice of production traffic (1%, then 5%, then 25%, then 100%) to the new version; observe error rates and latency at each step; auto-rollback on regression
Implemented with Argo Rollouts or Flagger driving traffic shifts via Istio or service mesh; metrics from Prometheus drive promotion decisions
Best for risky changes where you need real-traffic validation that pre-prod cannot provide — ML model updates, performance optimizations, new dependencies
Trade-off: slower (hours instead of minutes); requires service mesh or smart LB; needs solid SLO definitions to drive automated promotion

Practical guidance

Default to rolling for everyday changes; reach for canary on high-risk changes; reach for blue-green on atomic releases
Pair with feature flags to decouple deployment of binaries from rollout of features — makes the strategy choice less critical
Automate rollback: Argo Rollouts checking Prometheus rolls back faster and more reliably than humans staring at dashboards

03 · Deep dive