Blue-green deployment is a release strategy that runs two identical production environments, only one of which is live at a time, so a new version can be switched in with minimal downtime and a fast rollback path.
Key Points: • One environment ("blue") serves live traffic while the other ("green") is updated with the new version and tested in isolation. • Once the new version passes verification on the idle environment, traffic is switched over to it, typically at a load balancer or router level. • If something goes wrong after the switch, traffic can be routed back to the previous environment almost instantly, since it's still running unchanged. • This approach avoids the risk of deploying directly onto the environment currently serving users, since testing happens on a fully separate copy. • The cost is running two full production-sized environments, at least temporarily during the cutover window, which increases infrastructure spend.
Example: A team deploys version 2 of a checkout service to the idle "green" environment, runs smoke tests against it, then flips the load balancer so all traffic goes to green; if error rates spike afterward, they flip the load balancer back to "blue" within seconds.
Interview Tip: A concise interview answer is:
"Blue-green deployment keeps two identical environments, one live and one idle, and switches all traffic to the idle one once the new version is verified there. It gives a near-instant rollback by switching traffic back, at the cost of running two full environments during the cutover."