Rate limiting спасает приемник, когда вебхуки внезапно решают устроить шторм

Rate limiting спасает приемник, когда вебхуки внезапно решают устроить шторм

Если внешний сервис шлет события пачкой, первым падает не отправитель, а ваш хендлер. Лимитирование входа нужно не для красоты, а чтобы не убить БД, очередь и воркеры одним всплеском. Смотрим в тело запроса: без id события, типа операции и времени создания вы не сможете нормально резать поток.

Базовая схема простая: на ingress ставим ограничение по IP, токену или tenant_id, а дальше — bucket на ключ. Для Nginx это может выглядеть как:
limit_req_zone $binary_remote_addr zone=webhooks:10m rate=20r/s;
limit_req zone=webhooks burst=50 nodelay;
Но это только внешний фильтр. Внутри приложения нужен второй рубеж: очередь с bounded capacity и ответ 429, если буфер переполнен. Идемпотентность — это не роскошь, а база.

Не путайте rate limiting с throttling. Первый отсекает излишний вход, второй растягивает обработку. Если полезная нагрузка критична, лучше принять запрос быстро, положить событие в durable queue и отвечать 200 только после записи в журнал. Ретрай-политика решает всё: без backoff и джиттера клиент сам себе создаст DDoS.

Обязательно ведите метрики: входящий RPS, доля 429, глубина очереди, p95 времени обработки, число дубликатов по event_id. Когда растет 429, ищите не только лимит, но и медленные downstream-сервисы. Ловим 5xx на ровном месте — обычно потому, что кто-то решил, что один воркер и бесконечный буфер это архитектура.

Ставьте лимит на границе, подтверждайте прием только после durable write и проверяйте идемпотентный ключ до любых побочных эффектов.