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

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

Если внешний сервис шлет события пачками, приемник без ограничителя начинает ловить 5xx на ровном месте: пул соединений забит, база задыхается, ретраи добивают систему. Нормальная схема простая: сначала быстрый шлюз, потом очередь, потом воркер. Хендлер на входе должен отвечать быстро и предсказуемо, а не пытаться «успеть обработать все».

Базовый набор:
— лимит по IP / токену / tenant_id;
— ограничение по RPS и burst;
— отдельный лимит на тяжелые эндпоинты;
— таймаут на чтение тела и размер payload;
— circuit breaker, если downstream уже в агонии.

Если приемник живет за Nginx, режем поток там и не тащим мусор в приложение:
limit_req_zone $binary_remote_addr zone=webhooks:10m rate=20r/s;
server {
location /webhook {
limit_req zone=webhooks burst=40 nodelay;
client_max_body_size 1m;
proxy_read_timeout 5s;
}
}

Но rate limiting без идемпотентности — половина защиты. Смотрим в тело запроса, берем event_id или строим ключ из полезной нагрузки, кладем в Redis с TTL. Повторный дубль должен получать тот же результат, а не второй платеж, второй заказ и второй повод для ночного дебага.

Финал простой: ограничитель нужен не для красоты, а чтобы система деградировала контролируемо. Ретрай-политика решает всё, но только если приемник умеет говорить «стоп» раньше, чем у него закончится память, коннекты и терпение.