Один хук — много сервисов: как не устроить вебхук-спагетти

Один хук — много сервисов: как не устроить вебхук-спагетти

Fan-out — это когда входящий webhook не ходит по цепочке, а сразу раскладывается по нескольким потребителям. Один хендлер принимает payload, валидирует подпись, кладёт событие в очередь и уже оттуда раздаёт его в CRM, биллинг, аналитку и антифрод. Если дергать сервисы напрямую из HTTP-обработчика, получите классический зоопарк: один 500, и весь webhook начинает жить своей нервной жизнью.

Базовая схема простая: ingress -> broker -> workers. В ingress делаем только приём, дедупликацию по event_id и быстрый 2xx. В payload не верим, смотрим в тело запроса, проверяем schema, timestamp и signature. Идемпотентность — это не роскошь, а база: один и тот же хук придёт повторно, а обработка не должна создавать дубли в БД и внешних API.

Дальше каждому сервису — свой consumer и своя ретрай-политика. CRM может пережить задержку, биллинг — нет; значит, у них разные очереди, DLQ и лимиты параллелизма. Не связывайте fan-out с транзакцией в одном месте: упал один downstream — не блокируйте остальных. Ловим 5xx на ровном месте, считаем попытки, после N ретраев отправляем событие в dead-letter и поднимаем алерт.

Для надёжности держите у события метаданные: source, event_id, attempt, trace_id, created_at. Это позволяет дебажить маршрут без шаманства и быстро ответить на вопрос, где именно потерялся хук. Если fan-out нужен внутри одного сервиса, делайте его асинхронным; если между доменами — ещё и с контрактом на версию схемы.

Итог простой: входящий webhook должен завершаться быстро, а вся тяжёлая работа — жить в очередях и воркерах. Сначала приём, потом доставка; иначе любой внешний API устроит вам ночной инцидент.