Rate limiting — это не про жадность, а про выживание приемника под штормом событий

Rate limiting — это не про жадность, а про выживание приемника под штормом событий

Если вебхук может прилететь пачкой, приемник обязан не падать в лоб. Базовая схема: на входе nginx/ingress режет пик по IP/ключу, дальше хендлер кладет полезную нагрузку в очередь, а уже воркер разбирает её своим темпом. Не пытайтесь делать тяжелую бизнес-логику в синхронном обработчике: внешний сервис любит ретраи, а ваш процесс — память и лимиты.

Смотрим в тело запроса и выделяем ключ дедупликации: event_id, message_id, request_id. Если их нет — собирайте хэш от стабильных полей. Идемпотентность — это не роскошь, а база: одинаковый payload должен приводить к одному результату, иначе rate limiting лишь маскирует дубли, а не лечит их.

Полезные правила:
— 429 возвращаем только когда реально готовы попросить повторить позже;
— для burst-ограничения используем token bucket, для длинной нагрузки — leaky bucket;
— retry-after должен быть осмысленным, иначе клиент устроит DDoS своими ретраями;
— на 5xx отвечаем быстро, но в логах фиксируем причину и correlation_id.

Если приемник критичный, добавьте circuit breaker и отдельную очередь на медленные операции. Так шторма не превращаются в лавину падений, а вы ловите 5xx на ровном месте уже в контролируемой зоне.

Главное: ограничивайте вход, не теряйте события, и всегда проектируйте обработчик так, будто внешний сервис решит проверить вашу архитектуру на прочность.