Module store
Expand description
Pluggable storage traits for idempotency, rate limiting, and client state, shared between transport and backend-runtime crates.
Modules§
- client_
state ClientStateStoretrait and companion types for client-side state persistence.- idempotency
IdempotencyStoretrait and companion types for duplicate-execution protection.- ratelimit
- Rate limiting store trait and configuration types.
Structs§
- Bounded
Outcome - What
super::RateLimitStore::consume_boundedreturns: the ordinary decision, plus which bucket produced it. - Bucket
Budget - A cap on the number of distinct bucket keys one scope may create in a window, plus where traffic beyond the cap is charged instead.
- Consume
Request - One token-consumption request: the bucket the caller asked for, the token-bucket parameters, and optionally the budget that governs whether that bucket may be created at all.
- InMemory
State Store - Json
File State Store - Persisted
Client State - 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.
- Request
Journal Entry
Enums§
- Charged
- Which bucket a
super::RateLimitStore::consume_boundedcall ended up charging, and why. Purely observational — the decision itself is carried byBoundedOutcome::decision— but it is what lets the middleware log an in-progress amplification attempt instead of silently absorbing it. - 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.
Constants§
- MAX_
TTL_ SECS - Ceiling on any store-side TTL, in seconds: one year.
Traits§
- Client
State Store - Idempotency
Store - 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).
Functions§
- bucket_
ttl_ secs - How long an idle bucket stays relevant: the time to refill a full
bucket plus a minute of slack, clamped to
[60s, 24h]. - scope_
ttl_ secs - How long a scope’s admission record must live: at least as long as the buckets it admitted, and at least the caller’s requested floor.