operations
Deployment Strategies
Ship new versions safely — blue-green, canary, rolling, feature-flagged — depending on risk tolerance and the cost of a bad release.
Deploying a new version is the moment of maximum risk in a service's life, because a bad release can take down production. The naive approach — stop the old version, start the new one — causes downtime and exposes every user to a regression at once. Modern deployment strategies exist to ship safely: to release with no downtime, limit the blast radius of a bad version, and make rolling back fast and cheap.
Tasting a new recipe on a few diners before serving it to the whole restaurant — and keeping the old dish ready to bring back instantly.
Key Concepts
1
The main strategies trade safety against cost. A rolling deployment replaces instances of the old version with the new one a few at a time, so there is no downtime and only modest extra capacity is needed, but for a while both versions run together (which the services must tolerate) and rollback means rolling forward again. Blue-green keeps two complete environments — the live one (blue) and the new one (green) — and cuts traffic over all at once when green is verified, giving an instant switch and an instant rollback by flipping back, at the cost of running double the infrastructure. Canary releases route a small percentage of real traffic to the new version, watch its error rates and latency, and gradually increase the share if it stays healthy or abort if it does not — the best blast-radius control, at the cost of more sophisticated traffic routing and monitoring. Feature flags decouple deploy from release entirely: you ship the code dark and switch the feature on for a cohort at runtime, enabling instant kill switches and A/B testing without redeploying.
2
The framing interviewers want is matching the strategy to risk and cost: rolling for routine low-risk changes, blue-green when you need an instant switch and can afford duplicate environments, canary for high-risk changes where limiting exposure matters most, and feature flags layered on top to separate releasing a feature from deploying its code. Two cross-cutting requirements underpin all of them — backward-compatible changes (especially database migrations that work with both old and new versions during the overlap) and good monitoring to detect a bad release and trigger an automated rollback before users are widely affected.