Rate limiting спасает приемник, когда вебхуки внезапно превращаются в шторм

Rate limiting спасает приемник, когда вебхуки внезапно превращаются в шторм

Если внешний сервис шлёт события пачками, без лимита вы быстро получаете очередь, таймауты и каскадные ретраи. Правильная защита выглядит не как “рубильник”, а как набор правил: ограничить RPS, сгладить пики и сохранить возможность догонять хвост без потери данных.

Базовая схема: на входе проверяем подпись, потом кладём полезную нагрузку в очередь, а уже воркер решает, сколько брать за раз. Для синхронного хендлера держите короткий путь: ответ 2xx сразу, тяжёлую обработку — отдельно. Идемпотентность — это не роскошь, а база: event_id, dedup key, TTL в хранилище.

Если лимит задаётся по IP или токену, не верьте одному слою. Nginx режет грубый поток, приложение режет по бизнес-ключу, очередь сглаживает пики. Пример для edge:
limit_req_zone $binary_remote_addr zone=webhooks:10m rate=20r/s;
server { location /hook { limit_req zone=webhooks burst=100 nodelay; } }

Отдельно продумайте ответ на перегрузку: 429 для честного throttling, 503 если downstream уже лежит. Ретрай-политика решает всё: без jitter и max attempts отправитель устроит вам бесконечную карусель. Ловим 5xx на ровном месте, но не даём им стать нормой.

Держите лимит на входе, очередь внутри и дедупликацию в обработчике — тогда шторм событий останется шумом, а не инцидентом.