Rate limiting: как не положить приемник шторма́ми событий

Rate limiting: как не положить приемник шторма́ми событий

Если вебхук-источник начинает стрелять пачками, первый удар принимает не бизнес-логика, а ваш хендлер. Поэтому лимит ставят не «для красоты», а чтобы защитить очередь, БД и downstream от лавины ретраев и дублей.

Схема рабочая и скучная: на входе — быстрый 200 OK после валидации подписи и минимального парсинга; дальше событие уходит в очередь, где уже живут ретраи, дедупликация и backoff. Синхронно делать только то, без чего нельзя принять решение: проверить секрет, idempotency key, формат тела.

Rate limiting лучше строить по нескольким осям:
• по IP или подсети источника, если он предсказуем;
• по API key / tenant / webhook_id, если источников много;
• по типу события, потому что один и тот же клиент может слать разные нагрузки.
Идемпотентность — это не роскошь, а база: лимит без дедупа лишь замедляет катастрофу.

Если нужен жесткий контроль, ставьте token bucket или leaky bucket перед обработчиком, а не внутри него. На уровне Nginx это часто выглядит так:
limit_req_zone $binary_remote_addr zone=hooks:10m rate=20r/s;
server {
location /webhook {
limit_req zone=hooks burst=40 nodelay;
proxy_pass http://app;
}
}

Не забывайте про поведение при 429 и 5xx: клиент должен понимать, когда повторять, а когда остановиться. Если источник ваш — закладывайте ретраи с экспоненциальной паузой и джиттером. Ловим 5xx на ровном месте обычно там, где лимит есть, а очередь не рассчитана.

Итог простой: режьте нагрузку до входа, квитируйте быстро, а бизнес-работу уносите в очередь. Тогда шторм событий останется шумом в логах, а не инцидентом в проде.