Rate limiting на приёмнике вебхуков: как не утонуть в шторме событий

Rate limiting на приёмнике вебхуков: как не утонуть в шторме событий

Партнёрская сеть может начать слать 10 000 хуков одновременно — особенно после долгого простоя когда накопилась очередь ретраев. Твой сервер должен это выдержать или корректно сигнализировать о перегрузке.

Основной механизм: возвращать 429 Too Many Requests с заголовком Retry-After. Нормальные отправители это уважают и замедляются. Это лучше чем дать серверу лечь под нагрузкой.

Realize на уровне nginx:
```
limit_req_zone $binary_remote_addr zone=webhook:10m rate=100r/s;
limit_req zone=webhook burst=500 nodelay;
```

По смыслу: 100 запросов в секунду с всплеском до 500 без задержки. Всё что выше — 429.

На уровне приложения: токен-бакет алгоритм через Redis. Разные лимиты для разных отправителей — трекеру можно больше, тестовому источнику — меньше.

Асинхронная обработка — лучшая защита: принимай хук, кидай в очередь, возвращай 200. Обработчики в очереди масштабируются независимо. Сервер приёма практически не имеет нагрузки — он только пишет в Redis/RabbitMQ.

Мониторь: если 429 появляются в логах — либо кто-то атакует, либо у тебя пик активности который нужно было предусмотреть заранее.