Traffic controls
Rate limits, caching, request validation, traffic splitting and mirroring.
These controls are set per route.
Controls
| Control | Behaviour |
|---|---|
| Rate limiting | Limits requests per caller or per client IP. |
| Response caching | Serves repeated responses from a per-route cache. |
| Request validation | Checks JSON request bodies against a schema before forwarding. Invalid requests do not reach the target. |
| Traffic splitting | Sends traffic to several target groups by weight, for canary or blue-green releases. |
| Mirroring | Sends a copy of each request to a second target group. The copy's response is not read and does not change the client's response. |
| Route filters | A route can run a policy filter that allows or rejects a request before forwarding. If a required filter cannot load, the route fails closed with 503 instead of forwarding unfiltered. |
Mirroring and latency
In the current implementation the copy is sent from the same request handling path as the original, after the primary response is received. Connecting to the mirror (up to 500 ms) and sending the copy can add to the time before the client receives its response. A mirror failure does not change the response.
Mirroring sends real requests
A mirrored target receives the same requests, including POST and other requests with effects. Mirror only to targets where duplicates are safe.
Available at release
This page describes how Gateway behaves. How you define routes and targets, and how you authenticate, are published with the Gateway interface reference.