TrypemaTrypema
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.

Three paper-craft rate-limiter topologies showing local state, direct shared Redis state, and local state synchronized to Redis.
Local keeps state in one process; Redis centralizes every call; hybrid periodically synchronizes local state to Redis.

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
  • reads, conditional updates, and lifecycle mutations run through atomic Lua scripts

Build it

Create a Redis connection manager, then pass it to RedisRateLimiterProvider::builder(connection). Set a RedisKey prefix when multiple applications share one Redis deployment. The complete setup is in the Redis quickstart.

Operational notes

  • Redis 7.2+ is required
  • enable exactly one of redis-tokio or redis-smol
  • all cooperating instances should use the same limiter settings for the same namespace
  • unknown reads return zero values without creating per-key Redis state

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.

Local

In-process rate limiting with the lowest latency and no external dependencies.

Hybrid

Local fast-path admission with periodic Redis synchronization for very high throughput distributed workloads.