Traffic Management Patterns

The service mesh provides traffic management capabilities that are difficult to implement at the application level: canary deployments, traffic splitting, header-based routing, and fault injection. These capabilities turn deployments from binary events — the new version is live or it is not — into graduated processes where risk is controlled by traffic percentage.

1. Canary Deployments Route a small percentage of traffic — typically 1-5% — to the new version while the old version serves the rest. Monitor error rates, latency, and business metrics on the canary. If metrics are healthy, increase the percentage. If metrics degrade, route all traffic back to the old version. The canary catches production issues that staging could not reproduce because it runs against real traffic, real data, and real load.
2. Traffic Splitting Route traffic between versions by percentage, by header, or by source. A/B testing routes 50% of traffic to each variant. Feature flagging routes specific users to the new version. Geographic routing sends regional traffic to regional deployments. The mesh handles the routing; the application handles the logic.
3. Fault Injection Inject failures into the mesh to test resilience: delay injection adds latency to specific routes, abort injection returns error responses for a percentage of requests. Fault injection in the mesh tests the system's resilience without modifying application code. "What happens when the payment service responds with 500 for 10% of requests?" The mesh tells you without the payment service failing.