volga-rate-limiter

Crates.iovolga-rate-limiter
lib.rsvolga-rate-limiter
version0.8.1
created_at2026-01-18 11:29:13.157369+00
updated_at2026-01-25 10:54:08.691603+00
descriptionMacros for Volga Web Framework
homepagehttps://romanemreis.github.io/volga-docs
repositoryhttps://github.com/RomanEmreis/volga
max_upload_size
id2052228
size34,918
Roman (RomanEmreis)

documentation

https://docs.rs/volga

README

Volga Rate Limiter

A lightweight and efficient rate-limiting library for Rust.

This crate provides in-memory rate limiting algorithms designed for high-performance HTTP services and middleware.

latest latest License: MIT Build Release

💡 Status: Volga is currently in preview.
The public API may change while core abstractions are being finalized.

Overview

Rate limiting is used to control the number of requests that a client (or a group of clients) can perform within a given time window. Typical use cases include:

  • Protecting APIs from abuse or accidental overload
  • Enforcing fair usage policies
  • Applying different limits for anonymous users, authenticated users, tenants, or API keys

This crate focuses on per-node, in-memory rate limiting. It is intentionally simple and fast, and does not attempt to synchronize state across multiple processes or machines.

Algorithms

The following rate-limiting algorithms are provided:

  • [FixedWindowRateLimiter]

    • Counts requests in discrete, fixed-size time windows
    • Very fast and simple
    • May allow short bursts at window boundaries
  • [SlidingWindowRateLimiter]

    • Uses a sliding time window with linear weighting
    • Provides smoother request distribution
    • Slightly more expensive than a fixed window

Time Source Abstraction

All rate limiters are built on top of a pluggable [TimeSource] abstraction. This allows:

  • Deterministic and fast unit testing
  • Custom time implementations if needed

The default implementation, [SystemTimeSource], is based on std::time::SystemTime.

Concurrency Model

The rate limiters are designed to be:

  • Thread-safe
  • Lock-free or minimally locking on the hot path
  • Safe to share between async tasks and threads

Internal state is optimized for frequent reads and updates under high contention.

Scope and Limitations

  • This crate implements in-memory rate limiting only
  • It does not provide distributed coordination
  • For multi-node systems, rate limiting should be combined with external storage or coordination mechanisms (e.g. Redis, gateways)

Usage

The rate limiters are intended to be embedded into higher-level frameworks or middleware layers.

Commit count: 195

cargo fmt