governor

governor implements the Generic Cell Rate Algorithm (GCRA) for rate limiting in Rust, exposing direct (single-key), keyed (per-client), and stream/sink-based rate limiters with jitter support to avoid thundering-herd retries. It works in both std and no_std environments and integrates with async runtimes via futures-based streams and sinks.

As a general-purpose rate-limiting primitive, governor is widely used as the backing implementation for framework-specific middleware — including actix-governor and tide-governor — letting Rust web frameworks add rate limiting without each reimplementing GCRA themselves.

What You Get

• GCRA (Generic Cell Rate Algorithm) rate limiting with RateLimiter for direct, single-key limits
• Keyed rate limiters (backed by HashMap or DashMap) for per-client/per-key limiting
• Jitter support to spread out retry attempts and avoid thundering-herd effects
• no_std compatibility for embedded and resource-constrained environments
• Async integration via futures-based stream and sink wrappers

Common Use Cases

• Rate-limiting incoming requests per API key or per IP address in a Rust web service
• Backing rate-limiting middleware for frameworks like actix-web (actix-governor) or tide (tide-governor)
• Throttling outbound calls to third-party APIs with strict rate limits
• Implementing rate limiting in no_std/embedded Rust contexts where the standard library is unavailable

Under The Hood

Architecture - The crate’s core algorithm lives in gcra.rs, which implements the Generic Cell Rate Algorithm’s state machine (tracking a theoretical arrival time per key), while state/ provides the storage backends (in-memory HashMap/DashMap for keyed limiters, and a single-cell store for direct limiters); middleware.rs and the stream/sink integrations in the test suite (tests/streams.rs, tests/sinks.rs) layer async ergonomics on top of the same core GCRA state without duplicating the rate-limiting logic itself.

Tech Stack - A ~1,834-line no_std-compatible Rust library (edition 2018) with a minimal dependency footprint, optionally pulling in dashmap for concurrent keyed storage and futures/futures-executor for async stream/sink support; benchmarks use criterion, and property-based testing uses proptest with recorded regression cases (tests/proptests.regressions).

Code Quality - The test suite spans 11 dedicated integration test files (custom_hashers, keyed, keyed_hashmap, keyed_dashmap, direct, future, streams, sinks, middleware, memory_leaks, proptests) alongside criterion benchmarks, indicating deliberate coverage of both correctness and memory behavior; however, GitHub activity data shows very low recent commit velocity, suggesting the crate is stable/feature-complete rather than under active new-feature development.

API Design - The primary entry point, RateLimiter::direct() or RateLimiter::keyed(), is small and composable, and the crate’s no_std support and Clock abstraction (for injecting custom time sources, e.g. in tests) reflect careful attention to embedding governor into other libraries’ internals rather than only end-user application code — which is reflected in its adoption as the rate-limiting engine underneath other frameworks’ middleware crates.