<b>Rate limiting спасает приемник от шторма событий, если считать лимиты правильно</b>

<b>Rate limiting спасает приемник от шторма событий, если считать лимиты правильно</b>

Когда вебхук начинает сыпать пачками, приемник умирает не от нагрузки, а от хаоса. Нужны два барьера: ограничение входящего потока и отдельная очередь на обработку. Иначе ретраи провайдера превращают временный сбой в самострел: 429, дубли, рост latency и лавина повторных доставок.

Базовая схема простая: на входе считаем токены по ключу источника, дальше кладем событие в буфер. Если лимит выбран на уровне всей системы — один шумный клиент душит остальных. Если лимит только per-IP — провайдер с NAT или несколькими шлюзами ломает картину. Нормальный ключ — <code>source_id + event_type</code> или хотя бы <code>source_id</code>.

Решают не только лимиты, но и поведение при отказе:
• 2xx — только после успешной записи в очередь или БД
• 429 — когда лимит исчерпан, без героизма
• 5xx — только если реально не можете принять событие
• idempotency-key в заголовке или в payload, иначе дубли съедят пайплайн

Если нужен жесткий контроль, ставьте token bucket на ingress и отдельно ограничивайте воркеры. Так вы режете пик на входе, но не замираете внутри. Логируйте не только отказ, но и причину: лимит, размер тела, невалидный JSON, таймаут. Иначе в три часа ночи вы будете ловить 5xx на ровном месте без понимания, кто именно устроил шторм.

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