Rate limiting на API Gateway: кейс защиты от всплесков и abuse

Rate limiting — это баланс между защитой платформы и опытом клиента.

Проще говоря

Как внедрить rate limiting так, чтобы защитить систему и не убить легитимный трафик. Ниже — что именно делать на практике и где чаще всего ошибаются.

Рабочая стратегия лимитов

• global limit на tenant/client,
• route-level limit для тяжёлых операций,
• burst + sustained лимиты,
• отдельные лимиты для внутренних сервисов.

Сценарий из продакшена

Коротко про вводные.

Контекст: После запуска партнёрской интеграции один клиент создал 8x рост запросов за 20 минут.

Что сделали:

• включили token-bucket лимит на API key,
• добавили per-route лимит на тяжёлый поиск,
• вернули понятный 429 + Retry-After,
• выделили whitelisted канал для критичных webhooks.

Результат:

5xx снизились на 72%, latency вернулась к базовый уровень.

Ошибки внедрения

• один общий лимит «на всё»,
• нет наблюдаемость по top offenders,
• слишком агрессивные лимиты без staged поэтапный запуск,
• 429 без машиночитаемого retry guidance.

Что обязательно в проде

• dashboard с reject rate,
• алерт на резкий рост 429/5xx,
• policy review раз в месяц,
• договор по лимитам в документации API.

Короткая история из команды

В реальном проекте решение сработало только после того, как его закрепили в процессах команды, а не оставили на уровне договорённостей.

Вывод

Rate limiting работает только как продуктовая политика + техническая реализация, а не как случайная настройка gateway.

Как не задушить легитимный трафик

Перед жёсткими лимитами полезно запустить режим observe-only: собирать статистику по ключам и маршрутам без блокировок 7–14 дней. Это показывает реальные пики и помогает задать адекватные burst/sustained значения.

Отдельно стоит выделить whitelist-политику для критичных интеграций (например, платежные callbacks), но с верхними guard-лимитами, чтобы не создать дыру в защите.

Термины простыми словами

• Политика повторов — правила повторных попыток (когда, сколько раз и с каким backoff), чтобы не усилить сбой.
• Rate Limiting — ограничение частоты запросов для защиты ресурса и справедливого распределения нагрузки.
• Multi-tenant — модель, где одна система обслуживает несколько клиентов (tenant-ов) с логической изоляцией данных и доступа.
• Наблюдаемость — способность понимать внутреннее состояние системы по логам, метрикам и трассировкам.

Этот блок нужен, чтобы статью можно было читать без предварительного контекста по всем терминам.

Что делать команде прямо сейчас

Если хочется практики, а не теории, начни с короткого цикла на 2–3 недели. Выбери один проблемный модуль, зафиксируй «как есть» (латентность, ошибки, скорость изменений), внедри решение в минимальном объёме и проведи пост-анализ.

Дальше оформи выводы в инженерный стандарт: правило ревью, проверка в pipeline и короткий runbook. Такой формат даёт накопительный эффект и не требует «большого архитектурного проекта» каждый раз.