# Blue-green deployment > Blue-green deployment keeps two production-capable application environments: one serves users while the other receives the next release. After validating the new environment, you switch traffic to it and keep the previous environment available for rollback. This makes application releases easier to reverse, but it does not automatically make database changes or external side effects reversible. Source: https://sysround.com/concepts/blue-green-deployment Updated: 2026-11-05 ## How blue-green deployment works Start with blue serving production traffic and green isolated from public traffic. Deploy the new application version to green with production-compatible configuration, secrets, networking, and dependencies; the colors are just labels. Validate green before switching. Run readiness checks, smoke tests, and representative load tests, then warm caches and connection pools. For example, if blue handles 10,000 requests per second, green needs enough capacity to handle that load immediately after cutover. Switch new requests to green through a load balancer or reverse proxy. Routing changes may take time to propagate, and existing requests or WebSocket connections can remain on blue, so plan for a period when both versions are active. DNS alone gives less predictable cutover because of caching. Keep persistent state compatible with both versions. Blue and green commonly share a database, which requires backward-compatible schema and data changes. Separate databases require an explicit synchronization and write-ownership plan; switching application traffic does not solve those problems. Watch error rates, latency, resource usage, and business correctness after cutover. If the release fails, route new traffic back to blue, provided blue can still interpret the current data. Coordinate background workers and scheduled jobs separately so the inactive environment does not accidentally execute production work. Drain remaining blue connections and keep blue ready for a defined rollback window. Once the release is accepted, retire or reuse blue for the next deployment, and remove compatibility scaffolding only after old code can no longer run. ## Worked example: Switching an order API without losing rollback An order API receives 10,000 requests per second on 20 blue instances. Deploy 20 green instances, each tested to sustain 700 requests per second, and warm their connection pools. Both versions share the order database. Before deployment, add a nullable delivery_note column that blue safely ignores; do not rename or delete existing columns. After smoke tests, switch the load balancer to green and drain blue requests. Keep blue available for a 30-minute rollback window. If errors exceed the release threshold, route new requests back to blue. Orders already created by green remain in the database, so both versions must understand their status values. Delay destructive schema changes until rollback is no longer required. ## Trade-offs - **Fast application rollback, not automatic data rollback.** Reverting routing can restore the previous application version, but it cannot undo writes, payments, messages, or incompatible data changes. - **Extra deployment capacity.** Both application environments must be available during the release window, potentially requiring roughly twice the application serving capacity without necessarily duplicating shared storage. - **Large cutover blast radius.** A full traffic switch exposes the new version to the entire workload at once, unlike a canary rollout that limits initial exposure. - **Compatibility work.** Shared schemas, cache values, session formats, and event payloads must remain usable by both versions during overlap and rollback. - **Connection and worker coordination.** Long-lived connections need draining or reconnect behavior, while queue consumers and scheduled jobs need their own activation and shutdown rules. - **Validation has limits.** Pre-cutover tests cannot fully reproduce production traffic, and shared dependencies can still fail when green takes the full load. ## When to use it in a system design interview - The interviewer asks how to release a service with minimal interruption and a quick way to restore the previous application version. - The application tier is stateless or keeps sessions and durable state in stores accessible to both environments. - You can afford overlapping application capacity and can validate the replacement environment before it receives production traffic. - You need an explicit release cutover, and a full traffic switch is acceptable compared with gradually increasing exposure through a canary. ## How to bring it up in the interview - Name the switching mechanism: say that the load balancer changes backend target groups, rather than claiming the entire system switches atomically. - Define the rollback boundary: explain which application changes are reversible and which database writes or external side effects survive a rollback. - Describe an expand-and-contract schema change: add a compatible field first, deploy compatible code, and remove the old field only after the rollback window closes. - State release gates and rollback signals, including readiness, representative capacity tests, error rates, latency, and a business invariant such as successful order creation. - Expect probes about WebSockets, session storage, background workers, cache warmup, and how blue remains usable after green has written production data. ## Common mistakes - Calling blue-green deployment a guarantee of zero downtime without accounting for routing propagation, connection draining, or dependency failures. - Assuming switching back to blue reverses database migrations or external side effects. - Using independent blue and green databases without explaining synchronization, write ownership, and rollback after new writes. - Starting production consumers or scheduled jobs in both environments without controlling duplicate work or incompatible processing. - Confusing blue-green deployment with canary deployment: blue-green provides two environments and a cutover, while canary limits exposure through a partial rollout. ## FAQ ### What is the difference between blue-green and canary deployment? Blue-green deployment prepares a separate environment and switches production traffic to it. Canary deployment first exposes a small portion of production traffic to the new version, then increases exposure if it behaves correctly. You can combine them by gradually shifting traffic between blue and green. ### Does blue-green deployment guarantee zero downtime? No. It can avoid a planned application shutdown, but successful cutover still depends on capacity, readiness, compatible state, and connection handling. Long-lived connections may need a controlled reconnect rather than an immediate transfer. ### How do you handle databases in blue-green deployment? A common approach is to share the database and use expand-and-contract migrations so both application versions remain compatible. Separate databases require replication or change capture, a controlled transfer of write ownership, and a plan for writes made after cutover. Never assume application rollback also rolls back data. ## Related concepts - [Canary deployment](https://sysround.com/concepts/canary-deployment) - [Zero-downtime migrations](https://sysround.com/concepts/zero-downtime-migrations) - [Load balancing](https://sysround.com/concepts/load-balancing) - [Stateless services](https://sysround.com/concepts/stateless-services) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.