Rate limiting спасает приемник от шторма событий, если считать токены, а не надежды

Если вебхук валит события пачкой, приемник не должен принимать всё подряд. Нужен лимит на входе: по IP, по API-key, по tenant_id, по маршруту. Иначе один шумный клиент съедает пул воркеров, а остальные начинают ловить 5xx на ровном месте.

Базовая схема: Nginx/Envoy режет частоту на периметре, приложение проверяет квоты на уровне бизнес-ключа, очередь принимает только то, что можно обработать. На 429 возвращаем Retry-After, на переполнении — 503, если нужно дать отправителю шанс на ретрай. Главное — не молчать и не делать вид, что полезная нагрузка уже принята.

Для вебхуков почти всегда нужна связка:
• лимит по burst и среднему RPS
• дедупликация по event_id
• idempotency key в хендлере
• отдельная очередь на тяжелые задачи
• dead-letter для мусора и повторов

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

Смотрим в тело запроса, считаем метаданные, отсекаем шум до бизнес-логики. Идемпотентность — это не роскошь, а база: без нее любой rate limit превращается в генератор дублей, а не в защиту.