Deployment Strategies: Controlling Exposure to a New Version

A new version can be correct in testing and still fail under real traffic, data, configuration, or scale.

Deployment strategy determines how old capacity is replaced, how much exposure the new version receives, and how quickly the team can respond to evidence.

A deployment strategy controls the blast radius while confidence in a new version accumulates.

The strategy must include data and background processing, not only web servers.

A concrete example: a canary release

A new checkout version receives one percent of traffic.

The team compares:

• payment success,
• error rate,
• latency,
• duplicate orders,
• and user abandonment

with the stable version. Healthy evidence expands traffic to ten percent, then fifty, then all users.

If payment failures rise, traffic returns to the stable version.

Recreate deployment

A recreate strategy stops the old version and starts the new version.

Advantages:

• simple,
• no mixed versions,
• low duplicate capacity.

Disadvantages:

• downtime,
• risky startup failure,
• slower rollback.

It can suit internal tools with accepted maintenance windows.

Rolling deployment

A rolling deployment replaces instances in batches.

Some old and new versions run together. Capacity remains available if:

• batches are small,
• readiness is correct,
• enough healthy instances survive,
• and versions are compatible.

The rollout can pause when health declines.

Rolling compatibility

During a roll, versions may:

• read the same database,
• process the same queue,
• call each other,
• and share caches.

APIs, schemas, and message formats must support coexistence. A new writer should not produce data the old reader cannot understand.

Blue-green deployment

Blue-green maintains two environments:

• blue currently serves,
• green contains the candidate.

After verification, traffic switches to green. Blue can remain available for quick traffic rollback.

The method costs duplicate capacity and needs careful state handling.

Blue-green state

Application instances can be duplicated easily; databases cannot always be switched backward.

If green writes a new incompatible schema or external side effect, routing back to blue may not restore correctness.

Keep state compatible or plan a data migration and forward fix.

Canary deployment

A canary exposes a small slice of real traffic to the candidate.

Traffic can be selected by:

• percentage,
• employee group,
• region,
• account,
• device,
• or request characteristic.

The selected population should represent the risk being measured.

Canary analysis

Define success before rollout:

• error and latency thresholds,
• business conversion,
• resource use,
• data correctness,
• and minimum sample duration.

A short quiet canary may not exercise rare payment methods or peak load.

Automated analysis can pause or reverse expansion.

Feature flags

A flag can release behavior separately from deployment.

This enables targeted exposure inside one deployed version. It is useful for product behavior but does not protect against startup, dependency, or memory failures affecting the whole artifact.

Combine flags with deployment strategy according to the risk.

Shadow traffic

Shadowing copies real requests to a new system without using its responses.

It can test:

• performance,
• parsing,
• and output comparison.

Do not allow shadow requests to repeat payments, emails, or writes. Sensitive data handling and extra load also require review.

A/B testing versus canary

A canary asks:

Is the new version safe and healthy?

An A/B experiment asks:

Which experience produces a better product outcome?

The mechanisms can look similar, but experiment assignment and statistical analysis differ from reliability rollout.

Regional waves

Global services can release region by region.

Start with:

• internal region,
• lower-risk market,
• or small traffic location.

Regional rollout limits broad impact but must account for region-specific data, laws, integrations, and traffic patterns.

Readiness and health

New instances should receive traffic only after:

• startup completes,
• required dependencies are reachable,
• migrations are compatible,
• and warm-up finishes.

Liveness checks decide whether to restart; readiness decides whether to route traffic. Confusing them can create restart loops.

Connection draining

Before removing old capacity:

• stop new connections,
• let active requests finish,
• handle long streams,
• and return unfinished queue work safely.

Immediate termination creates errors and duplicates.

Background workers

Workers may not receive percentage-based web traffic.

Rollout options include:

• separate queue,
• partition assignment,
• small worker count,
• shadow processing,
• or feature flag.

Messages in backlog may use old schemas, so consumers need compatibility.

Database migrations

Use expand-and-contract:

1. add new structures,
2. deploy compatible readers and writers,
3. backfill,
4. switch behavior,
5. remove old structures later.

Destructive migration during the first rollout step can make rollback impossible.

Rollback triggers

Define:

• which metrics trigger pause,
• who can decide rollback,
• how fast traffic changes,
• and what happens to in-flight work.

Waiting for perfect certainty increases impact. A reversible rollout should favor early mitigation.

Cost

Strategies vary in temporary capacity:

• recreate uses least overlap,
• rolling uses limited extra capacity,
• blue-green can double environment cost,
• canary needs parallel versions and observability.

Cost should be weighed against outage and recovery risk.

Verification after completion

After full rollout:

• confirm every instance version,
• remove old capacity,
• verify queue consumers,
• inspect business metrics,
• clean temporary flags,
• and preserve deployment evidence.

The rollout is not finished merely because traffic reached 100 percent.

Knowledge check

1. Why must versions remain compatible during a rolling deployment?
2. What state problem can make blue-green rollback unsafe?
3. How does a canary differ from an A/B experiment?
4. Why do background workers need a separate rollout plan?
5. What does expand-and-contract protect?

The one idea to remember

Deployment strategies limit exposure while real evidence accumulates. Choose recreate, rolling, blue-green, canary, flags, or regional waves according to compatibility, state, traffic control, rollback, observability, and cost, then verify the entire system after rollout.