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

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

Если вебхук-хендлер принимает всё подряд, он быстро превращается в очередь боли: CPU уходит в парсинг мусора, БД ловит лишние записи, а ретраи добивают уже лежащий сервис. Rate limiting нужен не для красоты, а чтобы задать верхнюю границу ущерба.

Нормальная схема такая: на входе считаем токены по ключу sender_id, tenant_id или IP, а не по всему трафику сразу. Для каждого ключа задаём два режима: burst для кратких всплесков и steady-state для долгой нагрузки. Если лимит выбран, отвечаем 429 или кладём событие в отложенную очередь, но не пускаем его в основной пайплайн.

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

Практика простая: Redis для счётчиков, локальный in-memory лимит как страховка, экспоненциальный backoff для клиентов и отдельный лимит на тяжёлые методы. Ловим 5xx на ровном месте, когда один шумный источник забивает весь пул воркеров. Ретрай-политика решает всё, если она не делает шторм из шторма.

Ставьте ограничение как предохранитель, а не как наказание: сначала защитите приёмник, потом уже спорьте с отправителем о “правильной” частоте событий.