DEV Community: zlynv

Rate limiting algorithms explained: Token Bucket vs Sliding Window vs Fixed Window

zlynv — Sun, 25 Oct 2026 04:18:58 +0000

Rate limiting sounds simple: count requests, block when over the limit.
But the algorithm you choose changes how your API behaves under load.
Here's what's actually happening.

Fixed Window

The simplest algorithm. Count requests in a fixed time window (e.g. 60
seconds). When the counter hits the limit, block until the window resets.

Window: [0s -------- 30s -------- 60s]
Requests:  1  2  3  4  5 ... 30 = DENY
                                        Window resets
Requests:  1  2  3  4  5 ... 30 = DENY

Problem: boundary spikes. If the limit is 30/minute and a client sends
30 requests at 59s and 30 at 61s, they got 60 requests in 2 seconds.

Use when: login protection, payment endpoints, strict quotas.

Token Bucket

Each client gets a bucket of tokens. Tokens refill at a constant rate.
Each request costs one token. If the bucket is empty, the request is denied.

Bucket: [========] 8/10 tokens
Request costs 1 token → [=======] 7/10
Refill 1 token/sec   → [========] 8/10 (after 1s)

Key property: allows bursts. If you haven't made requests for a while,
your bucket fills up and you can burst above the average rate.

Use when: general API protection, where short bursts are acceptable.

Sliding Window

Like Fixed Window, but the window slides continuously. Instead of counting
in a fixed block, it counts requests in the last N seconds.

Window:   [------======------]
           now-60s   now
Requests:  1  2  3  4  5  6 = 6 in last 60s

Key property: no boundary spikes. Smooth rate limiting.

Use when: fair API usage, where you want consistent behavior.

GCRA (Generic Cell Rate Algorithm)

Used in telecom networks. Instead of counting requests, it tracks the
"theoretical arrival time" of the next allowed request.

Key property: very smooth, memory-efficient, no bucket to overflow.

Use when: high-throughput APIs, telecom-grade traffic shaping.

Leaky Bucket

Requests enter a bucket that leaks at a constant rate. If the bucket
overflows, requests are denied. Output is constant-rate regardless of
input spikes.

Input:   [======]   (burst)
Bucket:  [====]     (buffered)
Output:  [=]        (constant rate)

Use when: background jobs, queues, APIs that need constant processing rate.

Side-by-side

	Token Bucket	Fixed Window	Sliding Window	GCRA	Leaky Bucket
Bursts allowed	Yes	No	No	No	No
Boundary spikes	No	Yes	No	No	No
Memory per key	Low	Very low	Medium	Very low	Low
Smoothness	Medium	Low	High	Very high	High
Complexity	Medium	Low	Medium	Medium	Medium

The choice matters

Most rate limiters default to Fixed Window because it's simple. But Fixed
Window has the boundary spike problem: a clever client can get 2x the limit
by timing requests around the window boundary.

Token Bucket is usually the better default: it allows natural bursts while
still enforcing the average rate. If you need strict quotas (no bursts at
all), use Fixed Window explicitly.

In Python

from drogue.core.rules.rule import AlgorithmType

# Burst-friendly (default)
@limiter.limit("30/minute")

# Strict per-window quota
@limiter.limit("30/minute", algorithm=AlgorithmType.FIXED_WINDOW)

# Smooth, no boundary spikes
@limiter.limit("30/minute", algorithm=AlgorithmType.SLIDING_WINDOW)

All five algorithms are available. Pick based on your traffic pattern.

Full algorithm docs |
drogue on GitHub

How to rate limit FastAPI in 2026

zlynv — Sun, 25 Oct 2026 04:13:07 +0000

Rate limiting is the simplest defense against abuse. Here's how to add it
to a FastAPI app in 2026, step by step.

Install

pip install drogue[fastapi]

Basic rate limiting

from fastapi import FastAPI
from drogue.adapters.fastapi import DrogueLimiter

app = FastAPI()
limiter = DrogueLimiter(app, default_limits=["100/minute"])

@app.get("/api/data")
@limiter.limit("10/minute")
async def get_data():
    return {"data": "value"}

That's it. Every request gets a limit. Exceed it and you get 429 with
standard headers: X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After.

Per-route limits

@app.get("/api/public")
@limiter.limit("100/minute")
async def public():
    return {"ok": True}

@app.post("/api/login")
@limiter.limit("5/minute")    # strict: brute force protection
async def login(credentials: dict):
    return {"token": "..."}

@app.post("/api/upload")
@limiter.limit("10/minute")
async def upload(file: UploadFile):
    return {"filename": file.filename}

No request: Request needed. drogue extracts identity from the ASGI
context automatically.

Choosing an algorithm

from drogue.core.rules.rule import AlgorithmType

@app.get("/api/data")
@limiter.limit("30/minute", algorithm=AlgorithmType.FIXED_WINDOW)
async def get_data():
    return {"data": "value"}

Algorithm	Behavior	Use when
`TOKEN_BUCKET` (default)	Allows short bursts above average rate	General API protection
`FIXED_WINDOW`	Hard cap per window, no bursts	Login, payment, strict quotas
`SLIDING_WINDOW`	Smooth rate limiting, no boundary spikes	Fair API usage
`GCRA`	Telecom-grade smooth traffic	High-throughput APIs
`LEAKY_BUCKET`	Constant-rate processing	Background jobs, queues

Token Bucket is the default because it's burst-friendly. For brute force
protection on login endpoints, use FIXED_WINDOW.

Custom identity (not just IP)

from drogue.core.identity import HeaderExtractor

api_key_extractor = HeaderExtractor("X-API-Key")

@app.get("/api/data")
@limiter.limit("100/minute", key_func=api_key_extractor)
async def get_data():
    return {"data": "value"}

Available extractors:

RemoteAddressExtractor (default) - client IP with X-Forwarded-For anti-spoof
UserExtractor - user ID from request context
HeaderExtractor - custom header value
CompositeExtractor - combine multiple

Redis for multi-process

from drogue.core.storage.redis import RedisStorage

storage = RedisStorage(url="redis://localhost:6379")
limiter = DrogueLimiter(app, storage=storage, default_limits=["100/minute"])

With Redis, rate limits are shared across all workers and processes.

Custom 429 response

from starlette.responses import JSONResponse

def my_error(request, exc, headers):
    return JSONResponse(
        {"error": "slow_down", "retry_after": exc.retry_after},
        status_code=429,
        headers=headers,
    )

limiter = DrogueLimiter(app, error_renderer=my_error)

Rate limit headers are injected automatically.

WebSocket rate limiting

@app.websocket("/ws/chat")
@limiter.limit_ws("10/minute")
async def chat(websocket: WebSocket):
    await websocket.accept()
    ...

What's next

DDoS detection - Z-score anomaly detection
Auto-ban - progressive bans for repeat offenders
Trust scoring - 9x throughput for verified users
CAPTCHA challenges - Turnstile integration for page traffic

All off by default. Enable what you need.

pip install drogue[fastapi]

Full docs |
GitHub

Python rate limiting in 2026: drogue vs slowapi vs limits vs flask-limiter

zlynv — Sun, 25 Oct 2026 03:54:31 +0000

You're adding rate limiting to a Python web app. The usual suspects are slowapi, flask-limiter, django-ratelimit, and the limits library. There's also drogue. Here's how they compare.

The short version

	drogue	slowapi	flask-limiter	limits
`request: Request` in signatures	No	Yes	Yes	N/A (standalone)
FastAPI	Yes	Yes	No	Via adapter
Django	Yes	No	No	Via adapter
Flask	Yes	No	Yes	Via adapter
Algorithms	5 (Token Bucket, Sliding, Fixed, GCRA, Leaky)	1 (Fixed Window)	1 (Fixed Window)	3
WebSocket	Yes	No	No	No
DDoS detection	Yes	No	No	No
Auto-ban	Yes	No	No	No
CAPTCHA challenges	Yes	No	No	No
Shadow mode	Yes	No	No	No
Custom 429 body	`error_renderer`	Custom handler	Custom handler	N/A
Zero runtime deps	Yes	No (starlette)	No (flask)	No

The `request: Request` problem

This is the biggest difference and the reason drogue exists.

slowapi requires you to add request: Request to every decorated endpoint:

# slowapi
from slowapi import Limiter
from slowapi.util import get_remote_address
from starlette.requests import Request

limiter = Limiter(key_func=get_remote_address)

@app.get("/api/data")
@limiter.limit("10/minute")
async def get_data(request: Request):   # rate limiter leaked into your signature
    return {"data": "value"}

Now your business logic is coupled to the rate limiter. Change the limiter,
rewrite every endpoint. Test the endpoint without HTTP, mock the request.

drogue extracts identity from the ASGI context without touching your signature:

# drogue
from drogue.adapters.fastapi import DrogueLimiter

limiter = DrogueLimiter(app)

@app.get("/api/data")
@limiter.limit("10/minute")
async def get_data():                   # clean
    return {"data": "value"}

Algorithm choice matters

slowapi uses Fixed Window only. "30/minute" means exactly 30 requests,
then hard stop. That's fine for strict quotas but harsh on bursty traffic.

drogue defaults to Token Bucket, which allows short bursts above the average
rate. A "30/minute" limit with Token Bucket might briefly allow 35 requests,
then smooth out. For strict quotas, use algorithm=AlgorithmType.FIXED_WINDOW.

The choice between burst-friendly and strict-per-window is a design decision,
not a bug. slowapi just doesn't offer the option.

WebSocket rate limiting

Neither slowapi nor flask-limiter supports WebSocket rate limiting. If you
have real-time features (chat, notifications, games), you need drogue or
roll your own.

Built-in defense layers

drogue goes beyond rate limiting:

DDoS detection - Z-score anomaly detection across client rate distributions
Auto-ban - progressive ban with doubling duration (5m to 160m)
Trust scoring - 9x throughput for verified users (state machine: Unknown/Normal/Trusted/Distrusted/Banned)
CAPTCHA challenges - Turnstile integration with signed pass cookies and replay-proof tokens
Circuit breaker - Closed/Open/HalfOpen states for failing backends
Shadow mode - test rules without enforcing, collect metrics first

All off by default. Enable what you need.

Custom 429 responses

slowapi makes you replace the exception handler entirely. drogue gives you
a callback:

from starlette.responses import JSONResponse

def my_renderer(request, exc, headers):
    return JSONResponse(
        {"error": "rate_limited", "retry_after": exc.retry_after},
        status_code=429,
        headers=headers,
    )

limiter = DrogueLimiter(app, error_renderer=my_renderer)

Rate limit headers (X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After)
are injected automatically.

When to use which

Use drogue if you want clean signatures, multiple algorithms, WebSocket
support, defense layers, or you're migrating from slowapi and want less code.

Use slowapi if you're on FastAPI only, already have it integrated, and
don't mind request: Request in your signatures.

Use flask-limiter if you're on Flask and want something battle-tested.

Use limits if you need a standalone rate limiter (CLI tools, scripts, etc.)
without a web framework.

Install

pip install drogue[fastapi]   # or [django], [flask], [drf]

GitHub |
Full docs |
Migration guide

Every Python rate limiter has this DDoS blind spot — I built one that doesn't

zlynv — Sun, 02 Aug 2026 11:45:25 +0000

Every Python rate limiter has this DDoS blind spot — I built one that doesn't

10,000 bots hit your API. Each one sends exactly 1 request per minute. Every single bot is under your rate limit. Your slowapi or flask-limiter sees nothing wrong.

But your server is drowning.

I discovered this the hard way. After deploying slowapi in production for 6 months, I realized it had a fundamental blind spot: it counts requests, but it doesn't detect attacks.

So I built drogue — and tested it under real DDoS traffic.

The blind spot

Every rate limiter I tested works the same way:

# This catches overuse. It doesn't catch distributed attacks.
@app.get("/api/data")
@limiter.limit("100/minute")
async def get_data():
    return {"data": "value"}

The problem: rate limiting and DDoS detection are different problems.

Rate limiting catches single clients exceeding limits. It misses distributed attacks where each client stays under the limit.
DDoS detection catches anomalous traffic patterns. It's a different layer entirely.

Most Python libraries only solve the first one. I needed both.

What I tested

I benchmarked 5 rate limiting approaches under simulated DDoS traffic:

slowapi: Rate limiting only. No DDoS detection. No WebSocket support.
flask-limiter: Rate limiting only. Flask-specific. No DDoS detection.
pyrate-limiter: Rate limiting only. Algorithm-focused. No framework adapters.
ratethrottle: Rate limiting + DDoS detection + WebSocket support. No trust system.
drogue: Rate limiting + DDoS detection + WebSocket support + trust state machine + circuit breaker.

The key difference: drogue has a Z-score anomaly detector that learns what "normal" traffic looks like and flags statistical outliers.

How it works

drogue adds two layers that rate limiters miss:

1. Z-score anomaly detection

This tracks request rates per client and compares each client against the distribution of all client rates. When a client's rate deviates significantly from peers, it gets blocked. A client sending 5x more than the average gets flagged.

2. Progressive bans

After 5 violations, bans escalate automatically:

Level 1: 1 minute
Level 2: 10 minutes
Level 3: 1 hour
Level 4: 24 hours

Most libraries only count requests. drogue detects attacks.

The results

I ran a DDoS simulation with 50 concurrent users (mix of normal users and attackers):

Metric	Result
Total requests	42,815
Requests/sec	2,173.9
Attackers banned (403)	97.8% of attacker traffic
Rate limited (429)	0.02%
Successful attacks	0

97.8% of requests from attackers were banned. The remaining 2.2% were legitimate traffic that passed through. Note: this is the combined result of anomaly detection, progressive bans, and endpoint rate limits working together, not the anomaly detector alone.

Response time overhead: p50=5ms, p95=7ms, p99=10ms. Less than 10ms for most applications.

The feature comparison

Here's what drogue includes that others don't:

Feature	drogue	slowapi	flask-limiter
DDoS detection	Z-score	No	No
Progressive bans	Auto-escalating	No	No
Trust state machine	7 states	No	No
WebSocket protection	Yes	No	No
Circuit breaker	Yes	No	No
5 algorithms	TB/SW/FW/GCRA/LB	1	1
Framework support	FastAPI/Django/Flask/DRF	FastAPI	Flask

What I got wrong

My first attempt was simple: blacklist IPs that hit the endpoint too many times. It didn't work. Attackers rotate IPs every few minutes. By the time I banned one IP, they had already moved to another.

My second attempt: set a threshold of 1,000 requests per minute. If a client exceeds it, ban them. This also failed. The attack was distributed across 50,000 IPs. Each one was sending only 10 requests per minute. Every single bot was under the threshold.

The lesson: we can't catch a distributed attack with threshold-based rules. We need cross-sectional comparison across clients.

Where drogue is today

drogue's Z-score detector compares each client's rate against the distribution of all client rates. A client sending 5x more than peers gets flagged. This catches bursty attackers who stand out from normal traffic.

But it doesn't catch everything. If 50,000 bots each send exactly the same rate, no one is an outlier. And if attackers rotate IPs, bans don't follow them. These are hard problems that need browser fingerprinting and global traffic analysis, neither of which drogue does yet.

The core insight still holds: rate limiting alone isn't enough. But drogue is a step toward better protection, not a complete solution.

The counterintuitive truth

The fastest rate limiter isn't the best one.

drogue is slower than slowapi. 5ms overhead vs 2ms. That's a 2.5x difference. In benchmarks, slowapi wins.

But slowapi doesn't detect DDoS attacks. It doesn't ban attackers. It doesn't learn what "normal" traffic looks like.

Protection isn't about speed. It's about coverage.

Getting started

pip install drogue[fastapi]

from fastapi import FastAPI
from drogue.adapters.fastapi import DrogueLimiter

app = FastAPI()
limiter = DrogueLimiter(app, default_limits=["100/minute"])

@app.get("/api/data")
@limiter.limit("10/minute")
async def get_data():
    return {"data": "value"}

That's it. No request: Request. No configuration files. DDoS protection built in.

What's next

drogue v0.2.0 is out now with:

GCRA + Leaky Bucket algorithms
MongoDB storage backend
Thread safety guarantees
Full benchmark suite

v0.3 will add:

Redis-backed ban persistence
Trust cache sync across workers

Try it out

Have you been hit by a distributed attack that your rate limiter missed? I'd love to hear about it in the comments.

Building a Modern Rate Limiter and DDoS Protection Library for Python

zlynv — Wed, 29 Jul 2026 03:31:10 +0000

Rate limiting is one of those features every production API eventually needs.

Whether you're building a public REST API, a WebSocket service, or an authentication endpoint, you'll eventually face problems like:

Credential stuffing
Brute-force attacks
API abuse
Bots scraping your endpoints
Unexpected traffic spikes

Most applications solve this with a simple request counter.

But after building several APIs with Django, FastAPI, and Flask, I realized that production traffic requires much more than "X requests per minute."

That observation led me to build drogue, an open-source Python library for rate limiting and traffic protection.

The Problem

Traditional rate limiting is straightforward:

Allow 100 requests per minute.

This works well for many cases, but real-world applications quickly expose its limitations.

For example:

A distributed attack can remain below the per-IP limit.
A bot can rotate through proxies.
WebSocket connections often require different handling than HTTP requests.
Different endpoints need different protection strategies.

I wanted a system that could go beyond simple request counting.

Design Goals

From the beginning, I focused on a few principles.

1. Clean framework integration

I didn't want endpoint functions filled with framework-specific plumbing.

Instead, the library should feel like a natural extension of the framework.

from fastapi import FastAPI
from drogue.adapters.fastapi import DrogueLimiter

app = FastAPI()

limiter = DrogueLimiter(app, default_limits=["100/minute"])

@app.get("/users")
@limiter.limit("10/minute")
async def users():
    return {"status": "ok"}

No additional request objects.
No complicated middleware configuration.
Minimal boilerplate.

Multiple Rate Limiting Algorithms

Different applications require different algorithms.

Instead of supporting only one approach, drogue includes multiple options:

Token Bucket
Sliding Window
Fixed Window

Each has different trade-offs between accuracy, burst handling, and memory usage.

Beyond Rate Limiting

One thing I kept noticing was that abusive traffic often doesn't violate the configured limits.

An attacker may intentionally stay below the threshold.

That's why I started experimenting with additional protection mechanisms such as:

Traffic anomaly detection
Progressive temporary bans
Probe detection
Circuit breakers
CIDR filtering
Shadow mode for safely testing rules

Rather than replacing traditional rate limiting, these features complement it.

WebSocket Support

Many existing rate limiting solutions primarily focus on HTTP.

Modern applications increasingly rely on WebSockets for:

Chat applications
Live dashboards
Multiplayer games
Real-time notifications

Supporting both HTTP and WebSocket traffic from the same library became an important design goal.

Framework Support

Currently, drogue provides adapters for:

Django
Django REST Framework
FastAPI
Flask

The goal is to keep the developer experience as consistent as possible across frameworks.

Performance

Performance matters because rate limiting runs on every request.

The core package is designed with minimal overhead while keeping the implementation extensible enough for different storage backends and deployment scenarios.

Performance testing and optimization remain an ongoing part of development, and I plan to continue publishing benchmark improvements as the project evolves.

Lessons Learned

Building this project taught me several things:

Good APIs are often harder to design than efficient algorithms.
Framework integration significantly affects developer experience.
Rate limiting alone isn't enough for many production environments.
Clear documentation is just as important as clean code.
Simplicity usually wins over feature overload.

What's Next

There are still many ideas I'd like to explore, including:

Additional storage backends
More adaptive protection strategies
Better observability
Additional framework integrations
More comprehensive benchmarking

I'd Love Your Feedback

This project is still evolving, and feedback from the Python community is incredibly valuable.

If you build production APIs with Django, FastAPI, Flask, or another Python framework, I'd love to hear your thoughts.

What features do you look for in a rate limiting library?
What challenges have you encountered protecting public APIs?
Is there something missing that would make a library like this more useful?

The project is open source, and contributions, suggestions, and constructive criticism are always welcome.

Building infrastructure libraries is always a balancing act between performance, flexibility, and developer experience. Drogue is my attempt to make API protection easier without sacrificing clean application code.

If you're building production APIs with Django, FastAPI, Flask, or another Python framework, I'd love to hear your thoughts. Whether it's an issue, feature request, benchmark, or pull request, your feedback will help shape the project.

GitHub: https://github.com/zlynv/drogue
Documentation: https://zlynv.github.io/drogue/
PyPI: pip install drogue

DEV Community: zlynv

Rate limiting algorithms explained: Token Bucket vs Sliding Window vs Fixed Window

Fixed Window

Token Bucket

Sliding Window

GCRA (Generic Cell Rate Algorithm)

Leaky Bucket

Side-by-side

The choice matters

In Python

How to rate limit FastAPI in 2026

Install

Basic rate limiting

Per-route limits

Choosing an algorithm

Custom identity (not just IP)

Redis for multi-process

Custom 429 response

WebSocket rate limiting

What's next

Python rate limiting in 2026: drogue vs slowapi vs limits vs flask-limiter

The short version

The request: Request problem

Algorithm choice matters

WebSocket rate limiting

Built-in defense layers

Custom 429 responses

When to use which

Install

Every Python rate limiter has this DDoS blind spot — I built one that doesn't

Every Python rate limiter has this DDoS blind spot — I built one that doesn't

The blind spot

What I tested

How it works

Most libraries only count requests. drogue detects attacks.

The results

The feature comparison

What I got wrong

The counterintuitive truth

Getting started

What's next

Try it out

Building a Modern Rate Limiter and DDoS Protection Library for Python

The Problem

Design Goals

1. Clean framework integration

Multiple Rate Limiting Algorithms

Beyond Rate Limiting

WebSocket Support

Framework Support

Performance

Lessons Learned

What's Next

I'd Love Your Feedback

The `request: Request` problem