Rate limiting — это не «поставить лимит», а не дать приемнику умереть под штормом событий

Rate limiting — это не «поставить лимит», а не дать приемнику умереть под штормом событий

Если вебхук-хендлер принимает всё подряд, очередь растёт, ретраи множатся, а downstream начинает ловить 5xx на ровном месте. Нужны три слоя защиты: лимит на входе, буфер в очереди и отбрасывание дублей по idempotency key. Иначе один шумный источник превращает пайплайн в костыльный пожар.

Базовая схема простая: Nginx или API gateway режет поток по IP, токену или tenant_id; приложение отвечает 429; воркер уже решает, что делать с полезной нагрузкой. Важно не только отклонять, но и возвращать Retry-After, если клиент умеет читать заголовки. Если не умеет — будет долбить в лоб, и это уже проблема интеграции, а не магии.

Хороший лимит всегда привязан к реальной емкости системы, а не к желанию «чтобы было помягче». Смотрите на p95 latency, размер очереди, количество активных воркеров и время обработки одного события. Если хвост растёт, режьте вход раньше, чем база начнёт задыхаться. Ретрай-политика решает всё, но только если у вас есть куда складывать события, а не в пустоту.

Для практики хватит трех правил: 1) ограничивайте burst отдельно от sustained rate; 2) делайте лимит по ключу, а не только глобально; 3) фиксируйте причину отказа в логах и метаданных. Идемпотентность — это не роскошь, а база, иначе после 429 и повторной доставки вы сами себе устроите дубль-шторм.

Если приемник начал защищаться слишком поздно, он уже не приемник, а жертва. Смотрим в тело запроса, режем шум у края и не надеемся, что внешний сервис внезапно станет воспитанным.