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

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

Если внешний сервис умеет слать вебхуки пачками, ваш хендлер обязан пережить:
— всплеск после ретраев;
— дубли из-за повторной доставки;
— перекос по одному tenant’у или типу события.

Схема простая: на входе быстрый ACK, дальше — очередь, потом уже медленная обработка. Лимитировать лучше не только по RPS, но и по ключу: IP, tenant_id, user_id, webhook_id. Идемпотентность — это не роскошь, а база: без нее rate limiting превращается в лотерею, где вы либо теряете события, либо обрабатываете их дважды.

Практика: держите отдельные лимиты для read-подобных и write-подобных операций. Для burst используйте token bucket, для ровного потока — leaky bucket. Если лимит сработал, возвращайте 429, а не 500: 5xx провоцирует ретраи и только разгоняет шторм. Ретрай-политика решает всё, но только если она не питается вашими же ошибками.

Минимальный набор защиты: таймауты на чтение тела, ограничение размера payload, дедупликация по event_id, backpressure в очереди, circuit breaker на зависимые API. И да, логируйте причину отказа отдельно от бизнес-ошибок, иначе потом будете ловить 5xx на ровном месте.

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