Lesson 8 / 26

Weighted Traffic Splitting for Canaries

Send a small percentage of traffic to a new version and watch before widening.

Release to a few, then more

A canary release sends a small share of real traffic (say 1% to 10%) to the new version while the rest stays on the stable one. You compare error rate and latency between the two, and widen (10% → 50% → 100%) or roll back instantly by changing the weights, with no redeploy. Weighted splitting is a gateway or mesh feature (weight in nginx upstreams, weighted routes in Envoy/Istio, HTTPRoute backend weights in the Gateway API). Combine with sticky routing by user or header if a user should consistently see one version, and with automated analysis that halts the rollout when metrics worsen.

A 90/10 split (config)

Weights 9 and 1 in an nginx upstream give a 9:1 ratio. Excerpt of the gateway config.

upstream orders_weighted {
  server orders-v1:8080 weight=9;
  server orders-v2:8080 weight=1;
}

100 requests through the gateway, run

I ran this against a real nginx 1.27 gateway in Docker, with small Node.js services as upstreams (full setup in the case study). Out of 100 requests, exactly 90 were served by v1 and 10 by v2. nginx's weighted round robin is deterministic; probabilistic routers (random choice) only approach 90/10 as the sample grows.

# 100 calls to /orders/x with a valid API key, counting the version in each response

Output:

{"v1":90,"v2":10}

What a bad canary costs, run

I ran this plain-Python model. With 1,000 requests, a 10% canary receives 100. If the canary fails 5% of its requests, only 0.5% of all traffic is affected, which is why a small canary limits damage while still giving real data.

import hashlib, bisect, math, random

w1, w2 = 90, 10
n = 1000; print("expected canary requests:", n * w2 // (w1 + w2), "| error budget burned if canary fails 5%:", round(w2 / (w1 + w2) * 5, 2), "% overall")

Output:

expected canary requests: 100 | error budget burned if canary fails 5%: 0.5 % overall

Quick check: What is the main benefit of a canary release?

  • It makes servers faster
  • It removes the need for tests
  • A bad release affects only a small share of users and can be reverted quickly
  • It hides errors
Answer

A bad release affects only a small share of users and can be reverted quickly — Gradual exposure limits blast radius and gives real-world evidence.