Gateway Routing and Traffic Shaping Patterns

Gateway routing enables sophisticated traffic control by matching requests on path, headers, methods, query parameters, and custom attributes like tenant ID or device type. This pattern powers canary deployments, A/B tests, blue green releases, and gradual rollouts without client changes.

A typical canary starts at 1 percent of traffic to the new version, monitoring error rates and latency for 10 to 15 minutes, then ramps to 25 percent, 50 percent, and finally 100 percent. The gateway makes these splits based on a hash of request attributes or random sampling. For example, routing 5 percent of mobile users to a new recommendation engine while keeping web traffic on the old version. Shadow traffic is another powerful pattern where the gateway duplicates read only requests to a new service for validation without impacting real responses.

The challenge is managing routing complexity and preventing configuration drift. A single misconfigured route can shadow existing endpoints or bypass authentication. Netflix uses device specific edges (a form of Backend for Frontend) where different gateways serve mobile versus web versus TV clients, each with tailored routing and aggregation logic. This keeps any single gateway from becoming a god gateway monolith with hundreds of conflicting routes.

Versioning at the gateway typically uses either path based routing (slash v1 slash users versus slash v2 slash users) or header based content negotiation (Accept header specifying version). The gateway can gradually sunset old versions by logging usage metrics, returning deprecation warnings, and eventually blocking traffic after a transition period.

💡 Key Takeaways

•Canary deployments start at 1 percent traffic and ramp gradually (25%, 50%, 100%) over 30 to 60 minutes while monitoring error rates and latency percentiles

•Shadow traffic duplicates read only requests to new service versions for safe validation without affecting real user responses

•Backend for Frontend (BFF) pattern uses separate gateways per client type (mobile, web, partner) to avoid god gateway with hundreds of conflicting routes

•Path based versioning (slash v1 slash endpoint) or header based (Accept: application slash vnd.api plus json version equals 2) each have tradeoffs in client complexity versus routing clarity

•Configuration drift risk is high: misconfigured routes can shadow existing endpoints or bypass authentication requiring staged rollouts and automated policy tests

•Device specific routing allows tailoring payloads and experiments per platform: send smaller image sizes to mobile or enable beta features only for internal employee traffic

📌 Examples

E-commerce site routes 5% of checkout traffic to new payment service, monitors for 15 minutes, then ramps to 100% over 2 hours

Media streaming service runs separate BFFs: mobile gateway aggregates 5 calls into one for offline sync, web gateway returns full JSON for client side rendering

SaaS platform routes enterprise tier customers (identified by JWT claim) to dedicated backend instances with higher resource limits

← Back to API Gateway Patterns Overview