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

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

Если внешний сервис начал слать события пачкой, первый враг — не «производительность», а очереди, БД и зависшие хендлеры. Приемник должен резать поток до входа в бизнес-логику: по токену, по аккаунту, по IP, по tenant_id. Идемпотентность — это не роскошь, а база: при ретраях один и тот же payload обязан давать один результат, а не три дубля в таблице.

Рабочая схема простая: Nginx/Envoy режет грубый шум, приложение держит локальный лимит, очередь сглаживает пики. Для вебхуков полезен ответ 200/202 только после того, как событие записано в durable storage или в брокер; если не успели — 429/503 с Retry-After. Иначе отправитель решит, что все отлично, а вы ловите 5xx на ровном месте через час, когда диск уже забит.

Ключевые правила:
— лимитируйте не «всех», а источник и тип события;
— отделяйте публичный endpoint от внутреннего worker-пула;
— ставьте дедуп по event_id + tenant_id;
— для burst-трафика используйте token bucket, а не голый count/minute;
— не забывайте про backpressure: если очередь растет, режьте вход раньше, чем умрет БД.

Хороший rate limiting не ускоряет систему, а сохраняет ее в рабочем состоянии. Смотрим в тело запроса, считаем ключи, квитируем только сохраненное и не даем одному шумному интегратору утопить весь пайплайн.