Blue-Green Deployment

What is blue-green deployment?

Blue-green deployment is a release strategy where you maintain two identical production environments - Blue (current live) and Green (new version). When ready to release, you switch the load balancer to route all traffic from Blue to Green instantly. If something goes wrong, roll back by switching back to Blue.

How It Works

Users -> [Load Balancer] -> [Blue env: v1.0] (live)
                       -> [Green env: v1.1] (idle, being prepared)

Release:
Users -> [Load Balancer] -> [Green env: v1.1] (now live)
                       -> [Blue env: v1.0] (idle, ready for rollback)

1. Deploy new version to Green environment (while Blue serves production traffic)
2. Run smoke tests against Green (no user traffic yet)
3. Switch load balancer: Blue -> Green (instant cutover)
4. Monitor Green for 15-30 minutes
5. If healthy: decommission or repurpose Blue If unhealthy: switch back to Blue (instant rollback)

Advantages

• Zero downtime: cutover is a load balancer config change (milliseconds)
• Instant rollback: flip back to Blue if Green has issues
• Full production testing: smoke test Green before exposing to users
• Clean separation: no mixed versions running simultaneously

Disadvantages

Infrastructure Cost

Requires running two full production environments simultaneously during deployment. For large deployments, this can be expensive - especially databases, which can't easily be duplicated.

Database Migration Challenge

The hardest problem in blue-green deployment. When code and schema change together:

Problematic approach: Deploy new schema -> switch to green -> if rollback needed, old code doesn't understand new schema.

Safe approach - Expand/Migrate/Contract:

1. Expand: Add new columns (nullable, old code ignores them); both Blue and Green can use the database
2. Deploy Green: New code writes to new columns; old code still works
3. Contract (later): Remove old columns after Blue is decommissioned

Never remove or rename columns in the same deployment that uses them.

Stateful Services

Session state, in-flight requests, and persistent connections may be associated with Blue instances. On cutover, these sessions are lost unless session state is externalised (Redis).

DNS vs Load Balancer Cutover

Load balancer cutover (preferred):

• Change upstream server at L7 load balancer
• Instant - takes effect in milliseconds
• Old connections to Blue drain, new connections go to Green

DNS cutover:

• Change DNS record to point to Green IP
• NOT instant - DNS TTL means old record cached for minutes to hours
• Use short TTL (30-60s) if DNS cutover is your strategy

Blue-Green at the Database Level

For schema migrations that can't be done in-place:

• Run two database clusters (expensive and complex)
• Use an abstraction layer to route reads/writes to the appropriate cluster
• Migrate data in background while both clusters are live

Most teams avoid database-level blue-green and instead use backward-compatible schema migrations.

Interview Angle

Blue-green is a classic deployment question. Key points: instant rollback, zero downtime, double infrastructure cost, and the database migration challenge (expand/migrate/contract). Show that you understand it's not just about the app servers - databases are the hard part.