Rate limiting спасает приемник, когда вебхуки идут стеной и очередь начинает задыхаться

Rate limiting спасает приемник, когда вебхуки идут стеной и очередь начинает задыхаться

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

Базовая схема простая: на входе считаем запросы по ключу и режем лишнее. Ключ — tenant_id, user_id, IP, токен или комбинация. Ограничение лучше задавать отдельно для burst и sustained: короткий пик можно пережить, а постоянный поток — уже перегрузка. На превышении возвращаем 429, а не подвешиваем соединение в надежде, что проблема рассосётся.

Важно не только отказывать, но и делать это предсказуемо:
• лимит должен быть идемпотентным для повторов одного и того же события
• в ответе полезно отдавать Retry-After
• для критичных потоков ставьте очередь перед бизнес-логикой, а не сразу тяжелый обработчик
• лимитируйте не только внешний API, но и внутренние воркеры, иначе шторма переедут дальше по пайплайну

Если используете Nginx или API-gateway, не путайте сетевой лимит с бизнес-лимитом: первый защищает TCP/HTTP, второй — вашу модель данных. Смотрим в тело запроса, валидируем подпись, отбрасываем мусор до записи в БД. Идемпотентность — это не роскошь, а база.

Сначала режем лишнее на границе, потом уже разбираем полезную нагрузку. Иначе вы не строите интеграцию, а кормите прод собственными ретраями.