Проектирование и реализация ограничителя запросов

Условие

API‑шлюз принимает POST и GET запросы, включающие такие компоненты как балансировщик нагрузки (LB), модуль авторизации (Auth), TLS и ограничитель запросов (RL).

Необходимо спроектировать и внедрить механизм ограничения запросов (Rate Limiter):

• Определить, где лучше разместить ограничитель — непосредственно в API‑шлюзе, перед каждым микросервисом или в виде глобального сервиса.
• Поддержать различные типы лимитов: по IP‑адресу, по пользователю (created_by), по конкретному endpoint.
• Выбрать подходящие алгоритмы ограничения: Token Bucket, Leaky Bucket, фиксированное/скользящее окно.
• Решить, где хранить состояние ограничителя — в оперативной памяти, в Redis или в распределённом хранилище.
• Описать поведение при превышении лимита: возврат HTTP‑кода 429, запись в лог, возможная блокировка клиента.

Ответ

Разместите грубый IP-лимит на входе, а пользовательские и endpoint-лимиты — после проверки личности. Общие квоты нескольких шлюзов требуют согласованного состояния, например атомарной операции Redis.

Token Bucket допускает ограниченный всплеск; Leaky Bucket выравнивает скорость, фиксированное окно просто, но даёт всплески на границе, скользящее точнее и дороже. Ключ пользователя берите из проверенной авторизации, не из произвольного created_by. Учитывайте доверенные proxy и NAT для IP. Возвращайте 429 с Retry-After при применимости, логируйте агрегаты без секретов. Заранее выберите fail-open или fail-closed при сбое хранилища, TTL ключей и предел их числа.