Один хук на три сервиса: fan-out без потери событий и дублей

Один хук на три сервиса: fan-out без потери событий и дублей

Fan-out нужен, когда один входящий вебхук должен улететь в CRM, очередь и аналитку. Наивная схема «получили запрос — синхронно дернули все API» ломается быстро: один 5xx, и весь хендлер висит, ретраится и плодит дубли. Нормальная развязка — принять событие один раз, сохранить сырую полезную нагрузку и раздать её дальше асинхронно.

Базовый контур: webhook receiver отвечает 200 только после записи в хранилище или очередь. Дальше dispatcher читает событие и отправляет в подписанные сервисы. Если у сервисов разная судьба, не связывайте их в один транзакционный ком: у каждого свой retry, свой DLQ, свой статус доставки. Идемпотентность — это не роскошь, а база: event_id, digest тела и дедупликация на стороне получателя.

Схема метаданных простая:
{"event_id":"abc-123","source":"billing","type":"invoice.paid","payload":{...},"targets":["crm","warehouse","alerts"]}
В логах и трассировке храните один correlation_id на весь fan-out, иначе ночью будете ловить фантомные повторы и спорить, кто именно отвалился. Прокидываем стейт через метаданные, а не через магию в памяти процесса.

На практике работают три правила: 1) входящий хук не делает внешних вызовов синхронно; 2) каждый таргет изолирован; 3) ретраи с backoff и лимитом попыток обязательны. Если один consumer лег, остальные должны продолжать жить. Ретрай-политика решает всё.

Смотрим в тело запроса, режем событие по границе домена и раздаем дальше как независимые задания. Так fan-out превращается не в каскадный обвал, а в предсказуемый пайплайн.