Rolling update vs blue-green deployment

WHAT THIS TESTS: Whether you understand the spectrum of zero-downtime deployment strategies and can articulate the cost-risk-rollback trade-offs rather than naming buzzwords.

A GOOD ANSWER COVERS: A rolling update upgrades a service in place by replacing instances in batches, draining and updating a few at a time while the rest serve traffic. It needs only a small amount of extra capacity (often one batch worth), avoids downtime, but has two key consequences: during the rollout old and new versions run simultaneously and must be compatible (API and schema backward compatibility matter), and rollback means rolling the whole fleet back, which is comparatively slow. A blue-green deployment provisions a complete second environment (green) alongside the live one (blue), deploys and validates the new version on green, then switches traffic all at once via a load balancer or DNS. This gives a clean cutover with no version mixing and near-instant rollback by flipping traffic back to blue. The cost is roughly doubled infrastructure during the deployment and care around stateful components and database migrations.

COMMON WRONG ANSWERS: Saying rolling updates cause downtime (they are designed not to), forgetting that rolling forces version coexistence, or claiming blue-green is strictly better while ignoring its cost and database-state challenges. Conflating both with canary, which is a separate progressive-traffic strategy.

LIKELY FOLLOW-UPS: How do database schema changes complicate each strategy? Where does canary fit relative to these two? How do you handle long-lived connections during a blue-green switch?

ONE CONCRETE EXAMPLE: A stateless API uses rolling updates to save cost, accepting brief version mixing because its requests are backward compatible. A critical payments service uses blue-green so any regression can be reverted in seconds by flipping traffic back, paying double infrastructure during the short cutover window as insurance.