Rate limiter for FastAPI endpoints

[ronibhakta1]

To not get overwhelmed by any overloaded repeated attacks, we have to introduce the Rate limiter inside lenny!

If you are a new contributor feel free to drop a message how you plan to do it so that we can have better idea which suits our goals. Then I can assign the issue to you.

[Mishradity]

can you assign this to me

[Shikhar-395]

Since the Lenny API runs behind Nginx and may scale to multiple workers, the safest and most reliable setup is a two-layer rate-limiting system:

1- Nginx (Edge Layer)
Use limit_req to block high-volume or burst traffic before it reaches FastAPI.
Nginx uses the Leaky Bucket algorithm, which is ideal for flood protection.

2- FastAPI Layer – SlowAPI
Use SlowAPI for per-endpoint limits.
SlowAPI is built on top of the limits library, which uses Sliding Window (Moving Window) by default — the most accurate and fair algorithm for APIs.
Prevents boundary bursts, ensures fairness, and works well with Lenny’s usage pattern.

3- Redis Backend (for scaling)
If Lenny runs multiple FastAPI workers or is deployed across multiple instances, SlowAPI should use Redis so limits stay consistent across all workers.

3.1-Optional
Token Bucket is also possible (through limits), but Sliding Window is generally more accurate for API traffic.

@ronibhakta1 what do you think about this approach?

[ronibhakta1]

Since the Lenny API runs behind Nginx and may scale to multiple workers, the safest and most reliable setup is a two-layer rate-limiting system:

1- Nginx (Edge Layer) Use limit_req to block high-volume or burst traffic before it reaches FastAPI. Nginx uses the Leaky Bucket algorithm, which is ideal for flood protection.

2- FastAPI Layer – SlowAPI Use SlowAPI for per-endpoint limits. SlowAPI is built on top of the limits library, which uses Sliding Window (Moving Window) by default — the most accurate and fair algorithm for APIs. Prevents boundary bursts, ensures fairness, and works well with Lenny’s usage pattern.

3- Redis Backend (for scaling) If Lenny runs multiple FastAPI workers or is deployed across multiple instances, SlowAPI should use Redis so limits stay consistent across all workers.

3.1-Optional Token Bucket is also possible (through limits), but Sliding Window is generally more accurate for API traffic.

@ronibhakta1 what do you think about this approach?

We can try using SlowAPI with Nginx!

There are a few things I’d like you to take care of:

1. We have multiple endpoints, but a few of them should allow users to fetch details without being rate-limited too soon. For example, the /opds endpoint.
2. Lenny is also an engine, so we need to keep the TTL between compatible limits.

I’ve assigned this issue to you. Thanks for the update!

[rohitkrishna03]

Can I work on this issue ?, which is related to my previous work.