tower-rate-limiter
Keyed, fixed-window HTTP rate limiting middleware for Tower.
tower-rate-limiter lets an application decide who a request belongs to, what quota applies,
and where usage is stored. The middleware owns the charging and HTTP response flow without
coupling the core to Axum, Tokio, Redis, or a built-in identity policy.
Request
-> optional bypass
-> KeyExtractor
-> LimitProvider
-> Store::increment
-> allow the ready inner service or return a response
When to use it
Use this crate when you need per-caller HTTP enforcement in a Tower service, for example:
- one quota per authenticated account or API client;
- an IP-based limit at an application boundary;
- different quotas for free and paid plans;
- route-specific policies composed as Tower Layers;
- counters shared across processes through Redis.
This is not a global concurrency limiter or a backpressure mechanism. It charges requests to an application-defined client key and evaluates them against a fixed-window quota.
Design at a glance
| Concern | Application-facing seam | Included option |
|---|---|---|
| Caller identity | KeyExtractor | IpKeyExtractor |
| Quota selection | LimitProvider | fixed u64 via .limit(...) |
| Atomic usage | Store | MemoryStore, optional RedisStore |
| Error and rejection responses | ResponseFactory | DefaultResponseFactory |
The Store is always explicit. This makes the counter’s ownership and sharing boundary visible at layer construction instead of hiding process-local state behind a default singleton.
Cargo features
| Feature | Default | Adds |
|---|---|---|
memory | yes | Runtime-independent, process-local MemoryStore |
axum | no | Axum ConnectInfo<SocketAddr> support in IpKeyExtractor |
redis | no | RedisStore backed by an existing multiplexed connection |
redis-lua | no | Redis increment through Lua instead of MULTI/EXEC |
runtime-tokio | no | Tokio-compatible Redis async runtime |
runtime-smol | no | Smol-compatible Redis async runtime |
The Redis Store needs an increment implementation (redis or redis-lua) together with one async
runtime (runtime-tokio or runtime-smol).
With default-features = false, the core remains usable with application-provided implementations
and does not pull in Axum, Redis, or an async runtime.
Start here
- Follow the Quick start to construct a Tower layer.
- Browse the complete examples for progressively richer integrations.
- Review Configuration before choosing policy names, windows, and failure mode.
- Read How it works for exact charging semantics.
- Use Axum and Redis or implement Custom components.
- Check the Production guide before deploying behind a proxy or across replicas.
The API documentation is the complete type-level reference. The GitHub repository contains runnable examples.