Traffic control and quotas
ConceptProductSince version 0.1.0
Product guide: what the capability brings, for whom, its limits and the version that delivered it - no configuration syntax.
| What it does | Limits the rate per caller (its identity, not the address of the pod that relays), per request class or per operation; sets tenant quotas per day and per month; shares counters across replicas; sheds the lowest-priority requests when the gateway saturates |
| Why it matters | A noisy client no longer degrades the others. RateLimit-* headers are sent on successes too: a well-written client slows down before being refused. A refusal for your rate (429) is told apart from a lack of platform capacity (503) |
| Use cases | Sell a monthly volume of requests per customer; protect a costly operation with a bucket of its own; keep payments served while a heavy report is shed; count exactly across several replicas |
| Limits | Plans (a limit that depends on the customer's offer, read from a claim or a key) and budgets per user or per use case come in 1.8.0; a tenant quota requires a shared counter store (Redis, Dragonfly or Valkey) |
| Since | 0.1.0 (per-caller rate), 1.0.0 (shared counters, daily and monthly quotas, shedding, a bucket per operation) |
| Configure | Setting quotas |