<b>Rate limiting спасает приемник, когда вебхуки идут лавиной и начинают валить всё подряд</b>

<b>Rate limiting спасает приемник, когда вебхуки идут лавиной и начинают валить всё подряд</b>

Если внешний сервис шлёт события без тормозов, первым падает не очередь — падает ваш хендлер. Rate limiting нужен не «для красоты», а чтобы:
— не убить БД всплеском одинаковых записей;
— не устроить ретраи на 5xx из-за собственного же перегруза;
— не потерять контроль над latency, когда полезная нагрузка приходит пачками.

Делайте ограничение на входе, а не внутри бизнес-логики. Типовая схема: Nginx/ingress режет по IP, API-gateway — по токену или tenant_id, а приложение держит отдельный лимит на обработку ключевых маршрутов. На практике лучше два контура: один для принятия запроса, второй для фоновой очереди. Тогда при шторме вы честно отвечаете 429, а не кладёте весь пайплайн.

Критично учитывать идемпотентность. Если провайдер ретраит после 429, повторный event_id должен пройти через dedup-key и выйти без двойной записи. Смотрим в тело запроса, вытаскиваем ключ события, кладём в Redis с TTL, а уже потом решаем — запускать воркер или дропать дубль. Иначе rate limiting превращается в генератор фантомных инцидентов.

Практика простая: лимитируйте burst, ставьте bounded queue, мониторьте долю 429 и время ожидания в очереди. Если 429 растёт, а очередь пустая — проблема в лимите. Если 200 OK есть, а потребление стоит — проблема уже у вас, и это обычно хуже.

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