Expand description
Per-principal rate limiting.
Token-bucket algorithm with a pluggable store. The default in-memory
implementation is appropriate for single-instance deployments; banks
running multiple replicas bring a Redis-backed implementation through
the RateLimitStore trait so all replicas share the same view of
consumption.
The middleware computes a key per request (the default is the
authorization-header fingerprint, the same shape the idempotency layer
uses) and refuses with 429 plus a Retry-After header when the bucket
is empty. Banks running tenant-scoped budgeting can swap the key
function for tenant-id.
Structs§
- InMemory
Rate Limit Store - In-memory
RateLimitStore. Suitable for single-replica deployments and development; banks running multi-replica clusters need a Redis-backed implementation so the limit is enforced cluster-wide. - Rate
Limit Config - Configuration for a single bucket: capacity (max burst) and refill rate in tokens per second. Banks running high-frequency back-office traffic pick large bursts; consumer-facing channels use small bursts to dampen abuse.
- Rate
Limit Layer - Rate
Limit Service
Enums§
- Rate
Limit Decision - Result of attempting to consume a token.
Allowedcarries the number of tokens left after consumption;Throttledcarries seconds the caller should wait before retrying.
Traits§
- Rate
Limit Store - Pluggable storage for token-bucket state. Implementations must be safe to share across tasks (use a Mutex internally, or rely on the backing store’s atomicity).