Traffic Distributor (TD) is a routing layer that sits in front of two or more environments and shares incoming traffic between them according to rules you set. The three patterns below are the ones it was built for.
Blue/green deployment
Two environments hold the same application — one serving live traffic (blue), one staged with the next release (green). TD points all traffic at blue while you bring green up and validate it. When you flip the rule, every request starts hitting green.
The benefit: zero-downtime release with an instant rollback path. If green misbehaves, switching TD’s primary back to blue is a single click — no DNS propagation, no client reconnects beyond what the proxy layer already handles.
This is the most common reason teams install TD. The cutover is the safest moment of a release, and TD turns it into a routing decision instead of a deploy event.
Failover protection
Two environments, often in different regions or on different hardware footprints. TD treats one as primary and the other as standby, with a health check on the primary. When the primary stops responding, TD shifts traffic to the standby.
The benefit: tolerance of hardware-class issues — a region degradation, a host fault, a noisy neighbour. Your application keeps serving from the secondary while you investigate the primary.
Pair this with environment cloning to keep the standby in sync — the Traffic Distributor integration doc walks through the topology.
A/B testing
Two environments, two versions of the application. TD splits incoming traffic by ratio — 95/5, 50/50, whatever you set — so you can compare the two versions on live traffic.
The benefit: experimental release with statistical signal. You measure conversion, latency, error rate, or any application-side metric on the two arms and decide whether to roll the new version out to 100%.
The same machinery covers “canary” deploys — start with 1% on the new version, ramp up as you watch the dashboards.
What these patterns share
All three are variations on the same primitive: TD knows about two or more backends, and decides per-request (or per-client-session) which backend gets the request. The difference is how the decision is configured:
- Blue/green — one-of-two routing, you flip the switch
- Failover — one primary, one standby, the health check flips the switch
- A/B testing — both backends serve simultaneously, a ratio decides who gets which
When you understand the primitive, the patterns are interchangeable — a blue/green can be flown as a canary by setting an intermediate ratio, an A/B can be promoted to a full cutover by moving the ratio to 100/0, and so on.
Integrating with a running application
The trickiest part of adopting TD is not the routing itself — it is reorganising the entry point of an already-running application without dropping live traffic. The Traffic Distributor integration doc covers the two valid paths: swap-domains when the application uses a CNAME or ANAME, swap-public-IPs when it uses an A record.