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

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

Приемник без лимита — это не «быстро», а хрупко. Любой ретрай у внешнего сервиса, дубль события или всплеск из очереди превращают хендлер в бутылочное горлышко. Нормальная схема: на входе короткая проверка, дальше либо 2xx и запись в очередь, либо 429/503 с понятной политикой повторов.

Смотрим в тело запроса и режем по ключу, а не «на всех одинаково». Частые варианты:
— по tenant_id, если несколько клиентов делят один endpoint;
— по source + event_type, чтобы один шумный тип не душил остальные;
— по IP только как дополнительный фильтр, не как основная защита.
Идемпотентность — это не роскошь, а база: дубликат должен проходить в ту же ветку, а не создавать новый side effect.

На практике лимит лучше ставить в двух слоях: edge и приложение. Nginx умеет отсечь шторм до Python/Go-обработчика, а сам сервис держит свой токен-бакет или sliding window, чтобы не полагаться на прокси как на единственную линию обороны. Пример для edge:
limit_req_zone $binary_remote_addr zone=webhooks:10m rate=20r/s;
server {
location /hook {
limit_req zone=webhooks burst=40 nodelay;
proxy_pass http://app;
}
}

Если лимит сработал, отвечайте быстро и одинаково: 429 для явного троттлинга, 503 если не хватает внутренних ресурсов. Не делайте долгих блокировок и синхронных походов в базу на каждый чих. Ретрай-политика решает всё: короткий прием, запись стейта, асинхронная обработка, и только потом тяжелая бизнес-логика.

Пока нет лимита и дедупликации, любой внешний сервис может устроить вам ночной инцидент.