Providers
Redis
Best-effort distributed rate limiting backed by Redis 7.2+.
The Redis provider stores limiter state in Redis and evaluates operations through Redis-backed logic.
Why choose Redis
- limits are shared across processes and servers
- each decision sees current remote state as directly as this crate offers
- no local sync lag between admission and persistence
What to expect
- methods are async
- keys use
RedisKey - every check performs Redis I/O
- behavior is best-effort distributed, not strictly linearizable
Operational notes
- Redis
7.2+is required - enable exactly one of
redis-tokioorredis-smol - all cooperating instances should use the same limiter settings for the same namespace
Best fit
Choose Redis when shared state matters more than per-request latency.
If the Redis round-trip becomes the bottleneck, hybrid is usually the next step.