What
Configurable soft-enforcement mode for rate limiting. When a request exceeds a configured quota (e.g. token count), Praxis continues to forward the request but mutates it—typically by setting a well-known header—so downstream services can decide how to handle over-quota traffic.
Why
Hard 429 is a binary outcome. Soft annotation lets operators and customers implement custom handling (deprioritize, degrade quality, route differently, meter-only, etc.) without re-implementing the rate-limit evaluation itself.
Goals
- Per-rule configuration to choose enforcement action: hard reject (429) vs soft annotate (forward + mutate)
- Configurable annotation surface (at least: set/replace a request header with over-quota signal and optionally remaining/used quota metadata)
- Works with token-based quotas, not only request-count buckets
- Clear metrics/logs distinguishing soft over-quota vs hard throttle vs shadow (#548)
Non-goals (v1)
- Defining what downstream does with the annotation (customer/product-specific)
- Full dynamic fairness / runtime limit mutation (separate ask)
Related
- Parent discussion: #548
- Adjacent: #547 fail-open, #549 quota exhaustion failover
What
Configurable soft-enforcement mode for rate limiting. When a request exceeds a configured quota (e.g. token count), Praxis continues to forward the request but mutates it—typically by setting a well-known header—so downstream services can decide how to handle over-quota traffic.
Why
Hard 429 is a binary outcome. Soft annotation lets operators and customers implement custom handling (deprioritize, degrade quality, route differently, meter-only, etc.) without re-implementing the rate-limit evaluation itself.
Goals
Non-goals (v1)
Related