Support for rate limiting

[mrl5]

It seems there is no rate limiting feature yet. Having something simple like IP-based + fixed window (or leaky bucket) would be a great starter I suppose.

use cases

1. as an admin I'd like to rate limit requests towards my self-hosted analytics service per IP address
2. as an admin I'd like to rate limit logins of unauthenticated users

refs

• https://redis.io/glossary/rate-limiting/
• https://nginx.org/en/docs/http/ngx_http_limit_req_module.html
• https://blog.cloudflare.com/counting-things-a-lot-of-different-things/

[mrl5]

@notABot101010 I've created a draft PR #22 -- for now only how it could look from the configuration point of view

rules:
  rate_limit_api_routes:
    expression: http_request.path.starts_with("/api/")
    actions:
      - action: block
+   limit:
+     max: 10
+     window: 60

I was thinking that - optionally - also backend could be defined. For now default option is memory but could be extended in future to Redis and/or Postgres (not in scope of this PR)

rules:
  rate_limit_api_routes:
    expression: http_request.path.starts_with("/api/")
    actions:
      - action: block
    limit:
+     storage: redis # requires conn str in dedicated env var
      max: 10
      window: 60

When it comes to implementation I find the one described in https://blog.cloudflare.com/counting-things-a-lot-of-different-things/ quite compelling

[mrl5]

when it comes to per ip state updates I think there are 3 alternatives:

1. Awful bottleneck of Arc<Mutex<HashMap<...>>> -- definitely not
2. Re implementation (or usage) crates like scc / papaya / dashmap
3. Mimicking Redis architecture -- single threaded worker that handles ip state updates and communicates with the "hot path" via message passing (tokio::sync::mpsc)

I think (3) is the most compelling

[mrl5]

(probably) last missing design parts are:

• memory allocation for each rate limiter rule
• invalidation of stale entries

constraint

from https://kerkour.com/rust-pingoo-high-performance-allocations-mimalloc-heapless

Among other things, Pingoo analyzes every connection and request to block attacks, but it should do it by using a minimal amount of resources and it should never be your bottleneck. To achieve that, we spent and will continue to spend a lot of time optimizing every piece of code on the hot path.
(...)
Heap allocations: the performance killers

memory allocation

I think this is a choice between those 3:

1. std::collections::HashMap::new()
2. std::collections::HashMap::with_capacity(1024)
3. heapless::index_map::FnvIndexMap::<_, _, 1024>::new()

but also - in case of (2) and (3) - there are those questions:

• for the capacity -- should there be a customizable default (e.g. 1024), or should it always be required to define it?
• what should happen when Map is full?

--> I'd go with (3):

• pro: I think it reduces the possibility of OOM (esp. in side-car setups)
• pro: I think it should reduce the heap fragmentation
• pro: predictable memory footprint
• con: predefined rate limiter sizes since FnvIndexMap requires constant value for capacity
• con: it will occupy chunks of memory that most of the time will not be full

and

pub struct RateLimit {
    pub max: u16,
    pub window: u16,
+   pub max_ips: Option<usize>,
}

which mimicks NGINX:

Zone – Defines the shared memory zone used to store the state of each IP address.
(...)
The definition has two parts: the zone name identified by the zone= keyword, and the size following the colon. State information for about 16,000 IP addresses takes 1 ;megabyte, so our zone can store about 160,000 addresses.

invalidation of stale entries

I like the nginx approach described in https://blog.nginx.org/blog/rate-limiting-nginx

every time NGINX creates a new entry it removes up to two entries that have not been used in the previous 60 seconds.

UPDATE 2026-10-01: removed section about garbage collection that mimics NGINX -- it doesn't make much sense since we don't use leaky bucket. Instead I'd go with simple rotation of prev window and current window (see PR)

Last but not least -- Pingoo behavior when FnvIndexMap is full:

If storage is exhausted when NGINX needs to add a new entry, it removes the oldest entry. If the space freed is still not enough to accommodate the new record, NGINX returns status code 503 (Service Temporarily Unavailable).

This quote is a bit ambigious but I think that we should remove only expired entries, if it's not a case then HTTP 503