Deployment Strategies: Canary, Blue-Green & Safe Rollouts

Deployment Strategies

Why Engineers Care About This

Deployment strategies determine how new versions are released to production. Different strategies have different trade-offs—zero downtime, risk reduction, rollback speed. Understanding deployment strategies helps you choose the right approach for your needs. Without proper deployment strategies, releases cause downtime, bugs affect all users, or rollbacks are slow.

When deployments cause downtime, or bugs affect all users immediately, or rollbacks take too long, you're hitting deployment strategy problems. These problems compound. Without proper strategies, every deployment risks downtime and user impact. With poor strategies, bugs affect all users before detection. Good deployment strategies solve these problems by enabling safe, gradual releases.

In interviews, when someone asks "How would you deploy this to production?", they're really asking: "Do you understand deployment strategies? Do you know when to use blue-green vs canary vs rolling? Do you understand zero-downtime deployments and rollbacks?" Most engineers don't. They use simple deployments (stop old, start new) that cause downtime, or don't understand deployment strategies at all.

Core Intuitions You Must Build

• Blue-green deployment enables zero downtime and instant rollback. Blue-green deployment runs two identical environments (blue = current, green = new). Deploy new version to green, test it, then switch traffic from blue to green. If problems occur, switch back to blue instantly. This enables zero downtime and fast rollback, but requires double infrastructure (costly). Use blue-green for critical systems that need zero downtime.

• Canary deployment reduces risk by gradual rollout. Canary deployment releases new version to a small percentage of users (canary), monitors for issues, then gradually increases to all users. If problems occur, rollback affects only canary users. This reduces risk (bugs affect few users) but requires traffic splitting and monitoring. Use canary for risk reduction when you can't test fully before release.

• Rolling deployment updates gradually, one instance at a time. Rolling deployment updates instances gradually (one at a time or in batches), keeping some instances running old version while others run new version. This enables zero downtime and doesn't require double infrastructure, but rollback is slower (must rollback each instance). Use rolling for simplicity when infrastructure is limited.

• Deployment strategies require infrastructure support. Blue-green requires double infrastructure. Canary requires traffic splitting (load balancer, service mesh). Rolling requires instance management. Choose deployment strategy based on infrastructure capabilities. Don't choose a strategy your infrastructure can't support—it won't work.

• Health checks and monitoring enable safe deployments. During deployments, monitor new version health (error rate, latency, resource usage). If health degrades, rollback immediately. Also, use health checks to determine when deployment is complete (all instances healthy). Don't deploy without monitoring—you won't know if deployment succeeded or failed.

• Rollback strategies must be fast and reliable. When deployments fail, rollback must be fast (minutes, not hours) to minimize impact. Design rollback strategies—blue-green enables instant rollback (switch traffic), canary enables gradual rollback (reduce traffic to new version), rolling requires instance rollback (slower). Also, test rollback procedures—rollbacks that don't work are worse than no rollback.

Subtopics (Taught Through Real Scenarios)

Blue-Green Deployment

What people usually get wrong:

Engineers often think "blue-green is just having two environments." But blue-green requires careful traffic switching, health monitoring, and rollback procedures. Deploy new version to green environment, test it thoroughly, then switch traffic from blue to green. If problems occur, switch back to blue instantly. This enables zero downtime and fast rollback, but requires double infrastructure.

How this breaks systems in the real world:

A service used blue-green deployment but didn't test green environment before switching traffic. When traffic was switched, green environment had bugs that weren't caught in testing. All users were affected. Rollback to blue was slow (manual process), causing extended downtime. The fix? Test green environment thoroughly before switching, automate traffic switching, and test rollback procedures. Now blue-green deployments are safe and reliable. But the real lesson is: blue-green requires careful execution. Test before switching, automate switching, and test rollback.

What interviewers are really listening for:

They want to hear you talk about blue-green deployment, traffic switching, and rollback. Junior engineers say "just have two environments." Senior engineers say "blue-green runs two identical environments, deploys new version to green, tests it, switches traffic from blue to green, and enables instant rollback by switching back—requires double infrastructure but enables zero downtime." They're testing whether you understand that blue-green is about zero downtime and fast rollback, not just "two environments."

Canary Deployment

What people usually get wrong:

Engineers often think "canary is just testing with some users." But canary deployment requires traffic splitting, monitoring, and gradual rollout. Release new version to small percentage of users (canary), monitor for issues (error rate, latency), then gradually increase to all users. If problems occur, rollback affects only canary users. This reduces risk but requires infrastructure for traffic splitting.

How this breaks systems in the real world:

A service deployed new version to all users immediately. The version had a bug that affected all users, causing outages. The fix? Use canary deployment—release to 5% of users first, monitor for issues, then gradually increase. Now bugs affect only canary users, and rollback is fast (reduce traffic to new version). But the real lesson is: canary deployment reduces risk. Release gradually, monitor, and rollback if needed.

What interviewers are really listening for:

They want to hear you talk about canary deployment, traffic splitting, and risk reduction. Junior engineers say "just test with some users." Senior engineers say "canary deployment releases new version to small percentage of users, monitors for issues, gradually increases to all users, and enables fast rollback by reducing traffic to new version—reduces risk by affecting few users first." They're testing whether you understand that canary is about risk reduction, not just "testing."

Rolling Deployment

What people usually get wrong:

Engineers often update all instances at once, causing downtime. But rolling deployment updates instances gradually (one at a time or in batches), keeping some instances running old version while others run new version. This enables zero downtime without double infrastructure, but rollback is slower (must rollback each instance). Use rolling for simplicity when infrastructure is limited.

How this breaks systems in the real world:

A service updated all instances simultaneously. During update, all instances were restarting, causing downtime. Users experienced errors during deployment. The fix? Use rolling deployment—update instances gradually, one at a time, keeping some instances running old version. Now deployments have zero downtime. But the real lesson is: rolling deployment enables zero downtime without double infrastructure. Update gradually, not all at once.

What interviewers are really listening for:

They want to hear you talk about rolling deployment, gradual updates, and zero downtime. Junior engineers say "just update all instances." Senior engineers say "rolling deployment updates instances gradually (one at a time or in batches), keeping some instances running old version while others run new version—enables zero downtime without double infrastructure, but rollback is slower." They're testing whether you understand that rolling deployment is about gradual updates, not "updating everything."

---

• Blue-green deployment enables zero downtime and instant rollback—requires double infrastructure
• Canary deployment reduces risk by gradual rollout—affects few users first, requires traffic splitting
• Rolling deployment updates gradually—zero downtime without double infrastructure, slower rollback
• Deployment strategies require infrastructure support—choose based on infrastructure capabilities
• Health checks and monitoring enable safe deployments—monitor new version health during deployment
• Rollback strategies must be fast and reliable—test rollback procedures, automate when possible
• Good deployment strategies enable safe, gradual releases with minimal user impact

---

• CI/CD Pipelines - Automating deployments
• Health Checks & Monitoring - Health checks during deployments
• Kubernetes - Kubernetes deployment strategies