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

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

Если вебхук-эндпоинт принимает всплески событий без ограничений, он начинает ловить 5xx на ровном месте: очередь на запись растет, пул воркеров забивается, таймауты размазываются по всей цепочке. Лечится не «поставить побольше CPU», а явным ограничением входа на уровне API gateway, Nginx или самого хендлера.

Рабочая схема простая:
• ограничиваем RPS по ключу: токен, tenant, IP или комбинация;
• отделяем приём от обработки: быстрое 202/204, дальше — очередь;
• на превышение отдаём 429 с Retry-After, а не 500;
• ставим идемпотентный ключ, чтобы ретраи не плодили дубли.


limit_req_zone $binary_remote_addr zone=webhooks:10m rate=20r/s;

server {
location /hook {
limit_req zone=webhooks burst=50 nodelay;
proxy_pass http://app;
}
}


Важно не перепутать rate limiting и backpressure. Первый режет входящий шторм, второй говорит upstream: «я занят, притормози». Если провайдер умеет уважать 429 и Retry-After, включайте их. Если не умеет — ваш приемник должен сам жить в режиме деградации, а не героически падать.

Идемпотентность — это не роскошь, а база: один и тот же event_id должен безопасно проходить повторную доставку, даже если клиент ретраит после таймаута. Иначе rate limiting просто превращается в генератор расхождений между системами.