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

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

Fan-out нужен, когда один входящий webhook надо раздать в CRM, биллинг, логирование и антифрод. Ошибка новичка: сразу дергать все сервисы синхронно и считать 200 от внешнего API успехом. На деле вы получаете цепочку 5xx, таймауты и зависимость от самого медленного звена.

Правильная схема: принять запрос, проверить подпись, положить полезную нагрузку в очередь и сразу ответить 2xx. Дальше воркеры читают событие и маршрутизируют по подписчикам. На каждый получатель — свой retry policy, свой дедуп-ключ и свой DLQ. Идемпотентность — это не роскошь, а база: один и тот же event_id должен безопасно переживать повторную доставку.

Если сервисов много, не размазывайте логику по хендлерам. Сначала нормализуйте событие в общий формат:
{"event_id":"...","type":"lead.created","payload":{...},"meta":{"source":"...","ts":"..."}}
Потом уже решайте, кому это событие нужно. Фильтрация по типу и атрибутам дешевле, чем пытаться чинить каждый интеграционный зоопарк отдельно.

Отдельно смотрим на квитирование: подтверждаем прием только после записи в durable storage. Иначе при падении процесса получите «успешный» webhook, который никто не увидел. Ретрай-политика решает всё, но без backoff и лимита попыток она просто откладывает пожар.

Fan-out работает, когда вход, шина и потребители разделены. Один хук — это не один вызов, а один источник событий. Прокидываем стейт через метаданные, а не через надежду, и ловим 5xx на промежуточном слое, а не в проде у клиента.