Rolling vs blue/green deployments: differences and trade-offs

WHAT THIS TESTS: Whether you can reason about deployment topology, infrastructure cost, and failure recovery rather than reciting definitions. Interviewers want to see that you understand the resource and risk tradeoffs involved in pushing code to production.

A GOOD ANSWER COVERS: First, define rolling deployment as replacing instances gradually in the existing environment, often using a percentage based or batch approach, which means old and new versions coexist temporarily. Second, define blue/green deployment as standing up a complete duplicate environment, running validation, and shifting traffic all at once via DNS or load balancer changes. Third, compare tradeoffs directly. Rolling uses roughly baseline capacity so it is cheaper, but rollback is slow because you must redeploy the old version or reverse the sequence, and you may have compatibility issues between mixed versions. Blue/green requires double compute and storage during the cutover window so it is more expensive, but it provides instant rollback by switching traffic back and it eliminates mixed version states because only one color is live at a time.

COMMON WRONG ANSWERS: Saying blue/green is cheaper because you reuse servers, which is false because the strategy maintains two full stacks. Claiming rolling deployments require double capacity, which confuses them with blue/green. Stating that blue/green has zero downtime without mentioning the traffic switch mechanism or the need for data layer compatibility. Ignoring the database and state management problem entirely, since both strategies get harder when schema changes or session state are involved.

LIKELY FOLLOW UPS: How would you handle database schema changes with each strategy? What happens if the green environment passes health checks but fails under production traffic? How do you manage session affinity during a blue/green cutover? When would you choose a canary deployment over either of these?

ONE CONCRETE EXAMPLE: Imagine a web service running on ten EC2 instances behind a load balancer. In a rolling deployment, you take two instances out of service, update them, verify, then proceed to the next two until all ten are on the new version. Your bill stays flat but for several minutes five instances run the old build and five run the new one. In a blue/green deployment, you provision ten new instances with the new release, point a separate load balancer at them, run smoke tests, then flip the DNS record to the new stack. Your compute cost doubles for that window, but if error rates spike you flip traffic back in seconds.