Traffic Splitting: Route Live Traffic Between Service Versions

WHY IT EXISTS: Deploying new code to 100% of users at once is a high-stakes gamble. A single bug can cause a site-wide outage. Traffic splitting was created to de-risk deployments by allowing developers to expose new code to a small, controlled subset of live traffic first, limiting the blast radius of any potential issues.

THE MENTAL MODEL: Traffic splitting is a programmable traffic controller for your services. Instead of a coarse, slow-to-propagate DNS change, a service mesh or ingress controller makes routing decisions on a per-request basis. It's like a highway traffic controller who can be told, "Send 99% of cars down the main highway, but divert 1% onto this newly paved test lane."

HOW IT WORKS: In a Kubernetes environment, you run multiple deployments of the same application, distinguished by labels (e.g., version: v1 and version: v2). A service mesh proxy (like Envoy in Istio) or an ingress controller intercepts all requests. You define a rule, such as an Istio VirtualService, that specifies the weighting: "For requests to the reviews-service, send 90% of traffic to pods with label version: v1 and 10% to pods with version: v2." The proxy enforces this rule for each incoming request.

WHEN TO USE IT: The three main use cases are: first, Canary Releases, where you slowly increase traffic to a new version (1%, 5%, 25%, 100%) while monitoring metrics. Second, A/B Testing, where you route specific user segments (e.g., users with a certain cookie or header) to a different version to compare behavior. Third, Blue-Green Deployments, where you shift 100% of traffic from the old "blue" version to the new "green" version instantly after verification.

WHEN NOT TO USE IT: Avoid simple percentage-based splitting for stateful applications unless you also configure session affinity (sticky sessions). If a user's multi-step workflow depends on server-side state, bouncing them between v1 and v2 can corrupt their session and break the user experience. It is also overkill for simple apps in non-critical environments where a brief downtime for a standard rollout is acceptable.

ONE CANONICAL EXAMPLE: You have a payments service and deploy a new version, payments:v2. You configure your service mesh to send 99% of traffic to the stable payments:v1 and only 1% to v2. You watch your dashboards for v2's error rates and latency. If metrics are healthy, you update the rule to 90/10, then 50/50, and finally 0/100 to complete the rollout safely.