Traffic Shifting

The Primitive

 route requests between SUBSETS by weight:

 reviews service: subsets v1 (stable), v2 (candidate)

 route /reviews:
   v1: 90%    v2: 10%

 flip weights via config — no redeploys, no DNS, no app code.
 every proxy updates within seconds (xDS push).

 0→1%→5%→25%→50%→100% with health gates at each step =
 progressive delivery's engine (deployment lessons build here).

 [proxy]──90%──►[v1 pods]
        └─10%──►[v2 pods]     ← per-request dice roll

Beyond Percentages: Header-Based Splits

 steer by REQUEST CONTENT, not just dice:

 rules evaluated top-down:
 - header X-beta-user=true      → v2 (internal dogfood!)
 - cookie canary=enrolled       → v2 (opted-in users)
 - everything else              → weighted default

 uses that pay rent immediately:
 □ employee dogfooding before any customer sees v2
 □ specific TENANTS pinned during migration windows
 □ A/B assignment by user-id hash (stable bucketing)
 □ regional pinning during data-migration projects

 ordering semantics matter: most-specific match wins;
 document your precedence ladder before it becomes folklore.

The Stateful Complications

 stateless services shift trivially; watch for:

 □ SESSION affinity needs: sticky by hash → users straddle
   versions mid-flow unless consistent-hash routing used
   (and then: hot-key + rebalancing caveats return)
 □ SCHEMA/contract drift between versions: shared queues/
   DBs written by BOTH versions during transition must be
   backward-compatible both ways (expand-contract discipline)
 □ CACHE poisoning across versions: v2 writes cache entries
   in new format → v1 readers choke. namespace caches per version
   during shifts or keep formats compatible.
 □ WEBSOCKETS/long streams: shifting affects NEW connections
   only; old ones linger on v1 — drain windows needed.

 each is a "worked in staging, haunted prod" classic.

Operating Shifts Well

 □ GATES between steps are AUTOMATED: error-rate/latency
   deltas computed PER VERSION from mesh telemetry;
   regression halts promotion automatically
 □ ROLLBACK = previous weights (seconds, not minutes)
 □ MIRROR first when possible: send copy-traffic to v2,
   discard responses — validate under REAL load shadow-mode
   before any real shifting (next lesson's sibling)
 □ document CURRENT weights as runbook state; dashboards
   show live split so responders aren't archaeologists

Interview Framing

“Roll out a rewritten recommendations service safely” scored shape: subset+weight mechanics drawn, staged ladder with automated gates, header-based internal dogfood phase included, stateful gotchas named (caches/sessions), mirror-before-shift sequencing mentioned. Traffic-shifting questions test whether you treat rollout as a CONTROLLED SYSTEM STATE — percentages with guardrails, not a deploy button.