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

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

Если вебхук-хендлер без ограничителя, он превращается в бесплатный амортизатор чужих багов. Внешний сервис начинает ретраить, шлет дубликаты, ловит 5xx — и вы получаете лавину запросов, которая съедает CPU, соединения и очередь. Смотрим в тело запроса: один и тот же event_id должен проходить один раз, остальное — в мусор или в deferred-очередь.

Нормальная схема простая: на входе быстрый 200/202, дальше кладем событие в очередь, а лимитируем уже воркеры или периметр. Лимитер должен уметь считать по ключу: tenant_id, api_key, source_ip, тип события. Смешивать всех в один bucket — плохая идея, потому что один шумный клиент утопит остальных. Идемпотентность — это не роскошь, а база: без нее rate limit только маскирует дубль, но не решает его.

Практика:
— token bucket для пиков и коротких всплесков;
— leaky bucket, если важен ровный поток;
— отдельные лимиты на burst и sustained traffic;
— 429 с Retry-After, если хотите, чтобы ретрай-политика решала всё;
— circuit breaker, если апстрим начал сыпаться и надо временно гасить вход.

В логах фиксируйте ключ лимита, счетчик, причину отказа и correlation_id. Иначе потом будете героически ловить 5xx на ровном месте и гадать, это клиент, очередь или ваш же reverse proxy. Прокидываем стейт через метаданные, а не через надежду.

Если приемник нельзя деградировать gracefully, его все равно сломают — просто вопрос, кто первый: трафик, ретраи или собственная наивность.