<b>Rate limiting спасает приемник, когда вебхуки приходят не по одному, а штормом</b>

<b>Rate limiting спасает приемник, когда вебхуки приходят не по одному, а штормом</b>

Смотрим в тело запроса: лимитировать нужно не «весь трафик», а конкретный канал, тип события или tenant. Иначе один шумный клиент забьёт общий хендлер, а нормальные события начнут ловить 5xx на ровном месте.

Рабочая схема простая: на входе быстрый check, дальше — очередь, потом обработка. Если лимит превышен:
— отвечаем 429 или 503 без долгой логики;
— кладём payload в буфер/очередь с ключом идемпотентности;
— прокидываем стейт через метаданные, чтобы ретраи не плодили дубликаты.

Технически это можно сделать в Nginx, API gateway или в самом сервисе. Главное — лимитировать по token bucket или leaky bucket, а не по ощущению. Фиксируйте ключи: `tenant_id`, `event_type`, `source_ip`, `idempotency_key`. Если ключа нет, сначала нормализуйте полезную нагрузку, потом решайте судьбу запроса.

Идемпотентность — это не роскошь, а база: при ретраях приемник должен уметь сказать «я уже это видел» и не повторить бизнес-эффект. Ретрай-политика решает всё: без backoff и jitter любой внешний сервис устроит вам синхронный ддос собственными руками.

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