Skip to content
Go to file


Failed to load latest commit information.
Latest commit message
Commit time

Build Status Docs

ratelimit_meter is deprecated & in maintenance-only mode

In late 2019, I realized that a bunch of design decisions I made in ratelimit_meter (one of my first "real" rust projects) meant that some bugs were ~forever baked in. To fix that, I re-wrote the core of this library as governor. It is more fully-featured, more modern, less buggy and it has way less potential for buggy usage.

There is a migration guide available.

With the above in mind, please take the rest of this README with several grains of salt (and use governor if you can)!

Rate-Limiting with leaky buckets in Rust

This crate implements two rate-limiting algorithms in Rust:

ratelimit_meter is usable in no_std mode, with a few trade-offs on features.


Add the crate ratelimit_meter to your Cargo.toml file; the page can give you the exact thing to paste.

API Docs

Find them on for the latest version!

Design and implementation

Unlike some other token bucket algorithms, the GCRA one assumes that all units of work are of the same "weight", and so allows some optimizations which result in much more concise and fast code (it does not even use multiplication or division in the "hot" path for a single-cell decision).

All rate-limiting algorithm implementations in this crate are thread-safe. Here are some benchmarks for repeated decisions (run on my macbook pro, this will differ on your hardware, etc etc):

$ cargo bench
    Finished release [optimized] target(s) in 0.16s
     Running target/release/deps/ratelimit_meter-9874176533f7e1a0

running 1 test
test test_wait_time_from ... ignored

test result: ok. 0 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out

     Running target/release/deps/criterion-67011381a5f6ed00
                        time:   [1.9664 us 2.0747 us 2.1503 us]
                        thrpt:  [465.04 Kelem/s 482.00 Kelem/s 508.55 Kelem/s]
Found 10 outliers among 100 measurements (10.00%)
  4 (4.00%) low severe
  4 (4.00%) low mild
  2 (2.00%) high mild
                        time:   [2.4536 us 2.4878 us 2.5189 us]
                        thrpt:  [396.99 Kelem/s 401.96 Kelem/s 407.56 Kelem/s]
Found 8 outliers among 100 measurements (8.00%)
  5 (5.00%) low severe
  3 (3.00%) low mild

                        time:   [68.613 ns 68.779 ns 68.959 ns]
                        thrpt:  [14.501 Melem/s 14.539 Melem/s 14.575 Melem/s]
Found 13 outliers among 100 measurements (13.00%)
  9 (9.00%) high mild
  4 (4.00%) high severe
                        time:   [64.513 ns 64.855 ns 65.272 ns]
                        thrpt:  [15.321 Melem/s 15.419 Melem/s 15.501 Melem/s]
Found 16 outliers among 100 measurements (16.00%)
  4 (4.00%) high mild
  12 (12.00%) high severe

                        time:   [96.461 ns 96.976 ns 97.578 ns]
                        thrpt:  [102.48 Melem/s 103.12 Melem/s 103.67 Melem/s]
Found 11 outliers among 100 measurements (11.00%)
  4 (4.00%) high mild
  7 (7.00%) high severe
                        time:   [69.500 ns 70.359 ns 71.349 ns]
                        thrpt:  [140.16 Melem/s 142.13 Melem/s 143.88 Melem/s]
Found 9 outliers among 100 measurements (9.00%)
  6 (6.00%) high mild
  3 (3.00%) high severe

no-op single-element decision
                        time:   [23.755 ns 23.817 ns 23.883 ns]
Found 11 outliers among 100 measurements (11.00%)
  5 (5.00%) high mild
  6 (6.00%) high severe

no-op multi-element decision
                        time:   [22.772 ns 22.940 ns 23.125 ns]
Found 5 outliers among 100 measurements (5.00%)
  5 (5.00%) high mild

Contributions welcome!

I am actively hoping that this project gives people joy in using rate-limiting techniques. You can use these techniques for so many things (from throttling API requests to ensuring you don't spam people with emails about the same thing)!

So if you have any thoughts about the API design, the internals, or you want to implement other rate-limiting algotrithms, I would be thrilled to have your input. See for details!