Rate Limit (Ограничение частоты запросов к API)
(продолжение предыдущего поста)

Ограничение частоты запросов к API — это метод контроля количества запросов, которые клиент может отправить в определённый промежуток времени. Это защищает серверную часть от злоупотребления, обеспечивает справедливое использование сервиса среди клиентов и поддерживает стабильную производительность даже при высокой нагрузке.

Почему важно ограничивать частоту запросов к API

* Предотвращает перегрузку сервера.
* Блокирует вредоносные боты и попытки подбора методом перебора.
* Обеспечивает справедливое распределение ресурсов.
* Повышает надёжность и время безотказной работы API.
* Помогает контролировать расходы на API и использование инфраструктуры.

Основные методы ограничения частоты запросов

1. Ограничение по фиксированному окну (Fixed Window Rate Limiting)

* Запросы учитываются в рамках фиксированного промежутка времени (например, 100 запросов в минуту).
* Простота реализации.
* Может приводить к всплескам запросов на границах окон.

2. Журнал скользящего окна (Sliding Window Log)

* Фиксирует время каждого запроса в журнале.
* Более точное сглаживание трафика.
* Повышенное потребление памяти.

3. Счётчик скользящего окна (Sliding Window Counter)

* Объединяет методы фиксированного окна и журнала.
* Обеспечивает сглаженные ограничения без значительного объёма хранения данных.
* Снижает проблемы, связанные со «всплесками» запросов.

4. Алгоритм Token Bucket

* Клиенты накапливают «токены» с фиксированной скоростью.
* Каждый запрос использует один токен.
* Позволяет контролируемые всплески запросов при соблюдении ограничений.

5. Алгоритм Leaky Bucket

* Обрабатывает запросы с постоянной фиксированной скоростью.
* Очередь хранит избыточные запросы.
* Помогает сгладить колебания трафика.

Где применяется ограничение частоты запросов

* API‑шлюзы (Kong, NGINX, AWS API Gateway).
* Обратные прокси‑серверы.
* Уровень серверного приложения.
* Узлы CDN (Cloudflare, Akamai).
* Уровень взаимодействия микросервисов.

Типичные HTTP‑ответы при ограничении частоты запросов

* 429 Too Many Requests — клиент превысил лимит.
* Заголовок Retry‑After — указывает клиенту, сколько времени нужно подождать.

Лучшие практики

* Устанавливайте лимиты в зависимости от ролей пользователей (бесплатный тариф против премиум).
* Предоставляйте чёткие сообщения об ошибках с инструкциями по повторной попытке.
* Используйте системы кэширования, такие как Redis, для счётчиков.
* Регистрируйте все нарушения лимитов для анализа.
* Избегайте чрезмерно строгих ограничений, которые затрудняют использование сервиса.
* Применяйте адаптивные лимиты для различных нагрузок.