Traffic Shaping for Safer Deployments
In deployments, traffic shaping isn't about network speed, but controlling user exposure. You route a precise percentage of users to a new code version, slowly 'opening the valve' from 1% to 100% to de-risk the release. This is the engine of a canary deploy.
WHY IT EXISTS: Traditional 'big bang' deployments are risky, exposing 100% of users to potential bugs at once. The concept of traffic shaping was adapted for deployments to minimize this 'blast radius,' allowing for controlled, gradual rollouts that can be quickly reversed.
THE MENTAL MODEL: While network traffic shaping delays packets to manage bandwidth, in deployments it's a metaphor for controlling user flow. Think of it as a weighted routing system or a dimmer switch for your release. You have two versions of a service, and you decide exactly what percentage of users are routed to the new one.
HOW IT WORKS: This is typically managed by a layer 7 proxy, like an API gateway or a service mesh sidecar (e.g., Envoy). A control plane (e.g., Istio, a cloud load balancer) is given a rule like 'send 95% of traffic to service v1 and 5% to service v2.' The proxy intercepts each request, checks the rule, and forwards it to the appropriate service version. Engineers monitor metrics for v2 and adjust the percentage until it safely handles 100% of traffic.
WHEN TO USE IT: It's essential for implementing canary releases, blue-green deployments, and A/B tests for critical, user-facing applications. It allows you to validate performance, correctness, and business metrics on a small subset of real users before committing to a full rollout.
WHEN NOT TO USE IT: The infrastructure overhead (e.g., a service mesh) may be too high for simple, non-critical internal tools. It's also complex for stateful applications that require careful handling of database migrations and session affinity, as simply splitting traffic can lead to inconsistent user experiences.
ONE CANONICAL EXAMPLE: A team releases a new version of their API. They configure their API Gateway to route 1% of production traffic to the new version. They watch their observability platform, comparing the error rate and latency of the new version against the old. Seeing no issues, they increase the traffic to 10%. An hour later, an alert fires for increased latency on the new version. They immediately set the traffic percentage for the new version back to 0%, instantly mitigating the issue for all users while they investigate the performance problem offline.
Read the original → en.wikipedia.org
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.