Per-principal token-bucket rate limiting at HTTP ingress #3
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Context
The router's ingress today protects against capacity overflow with a per-capability FIFO bounded at 1000 pending. Producers receive
429 + Retry-Afterwhen the FIFO is full, and retries are deduplicated byIdempotency-Key.What's missing: per-principal limits. All asks from one authenticated principal share the per-capability FIFO with all other principals targeting the same capability. A single noisy or misbehaving producer can monopolise a FIFO and deny service to other legitimate principals.
Acceptable for the v0.1 deployment with a small number of trusted producers; not safe to expand to multi-tenant hosting or open producer onboarding without per-principal flow control.
Proposed change
Add a per-principal token bucket at the ingress layer, evaluated before the per-capability FIFO check.
burstandsteady_rate(asks/sec).burst = 50, steady = 10/s).subclaim → bucket parameters).429 + Retry-Afterwith the same shape as the FIFO-full response.Implementation: a
gen_serverper principal, garbage-collected after a configurable idle window.Acceptance
[ingress.rate_limit] default_burst = N, default_steady = M, idle_gc_seconds = K.rejected_countandcurrent_tokensexposed at/metrics.Refs
cbcl-runtimedeck slide 17 (Flow control)