Crate touch_ratelimit

Expand description

§touch_ratelimit

A composable, extensible rate limiting crate for Rust.

This crate provides building blocks for implementing rate limiting in Rust applications using a clean separation of concerns:

Algorithms define how rate limiting works (e.g. token bucket).
Stores define where rate limiting state is kept.
Middleware defines how rate limiting is applied to requests.
Adapters integrate rate limiting with web frameworks (e.g. Axum).

The design is framework-agnostic and allows different algorithms, storage backends, and adapters to be combined without modifying core logic.

§Core concepts

§RateLimiter

A bucket::RateLimiter represents the rate limiting logic for a single identity (for example, one user or one IP address).

§RateLimitStore

A storage::RateLimitStore maps request keys to individual RateLimiter instances and handles concurrency.

§Middleware

The middleware module provides Tower middleware that enforces rate limits before forwarding requests.

§Storage behavior

The default in-memory store keeps all rate limiting state inside the application’s memory:

State is lost on restart
State is not shared across processes

This is suitable for single-instance deployments and development. Distributed stores (e.g. Redis) can be added without changing middleware or algorithms.

§Example: Axum

use axum::{routing::get, Router};
use std::sync::Arc;
use touch_ratelimit::{
    adapters::axum::axum_rate_limit_layer,
    storage::in_memory::InMemoryStore,
    bucket::token_bucket::TokenBucket,
};

let store = Arc::new(InMemoryStore::new(|| TokenBucket::new(10.0, 1.0)));

let _ = Router::new()
    .route("/", get(|| async { "hello" }))
    .layer(axum_rate_limit_layer(store));

§Roadmap

Planned future additions include:

Additional rate limiting algorithms
Distributed storage backends (e.g. Redis)
Administrative inspection interfaces
Optional CLI tooling

§Non-goals

This crate does not:

Host infrastructure (e.g. Redis)
Provide a global service
Automatically persist rate limiting state

Infrastructure is always owned and configured by the user.

Modules§

adapters
bucket: Rate limiting algorithms.
errors
middleware: Tower middleware for rate limiting.
storage