Как ограничить трафик в FastAPI

Ограничение количества запросов в FastAPI можно сделать либо через специализированные библиотеки (например, slowapi или fastapi-limiter), либо на уровне reverse-proxy (Nginx), либо написав своё middleware. На практике чаще всего используют готовую библиотеку или настройки Nginx. Я бы упомянул оба подхода и кратко описал их плюсы.

Обычно rate limit в FastAPI реализуют тремя основными способами:

• через специализированные библиотеки: slowapi, fastapi-limiter и т.п.;
• на уровне reverse-proxy (чаще всего Nginx), не трогая сам код приложения;
• через собственную реализацию (middleware/зависимости), если нужны очень специфические правила.

1. Rate limit через библиотеки (пример со slowapi)

Вариант с библиотекой удобен тем, что почти всё уже реализовано: хранение счётчиков, парсинг правил вида "5/minute", обработка исключений. Пример с slowapi для ограничения 5 запросов в минуту на IP:

Здесь мы создаём Limiter и указываем key_func=get_remote_address, чтобы идентифицировать пользователя по IP. Для эндпоинта /home через зависимость Depends(limiter.limit("5/minute")) задаём лимит в 5 запросов в минуту; при превышении выбрасывается RateLimitExceeded, который обрабатывается стандартным хендлером библиотеки. Аналогично можно использовать fastapi-limiter, который работает поверх Redis и тоже позволяет описывать лимиты декларативно.

2. Rate limit на уровне Nginx (reverse-proxy)

Если перед приложением стоит Nginx, логично перенести ограничение трафика туда. Тогда FastAPI не тратит ресурсы на проверку лимитов, а все превышения отсекаются ещё до входа в приложение:

В этом примере limit_req_zone создаёт зону api_limit с лимитом 5 запросов в минуту на IP, а директива limit_req привязывает её к конкретному location. Такой подход удобен, если у вас несколько сервисов за одним Nginx или приложение написано не только на FastAPI.

3. Собственный (кастомный) вариант

Если нужны особые правила (сложная тарификация, гибридные лимиты по пользователю/клиентскому ключу и т.п.), можно написать своё middleware или зависимость, которая будет сохранять счётчики запросов (например, в Redis) и выбрасывать HTTP-ошибку при превышении лимита. Это требует больше кода и тестов, но даёт полный контроль над логикой.