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

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

Если внешний API шлёт один webhook, а дальше его надо разнести в CRM, очередь, аналитку и нотификации, прямой вызов всех хендлеров из HTTP-пути — плохая идея. Упавший сервис превращает весь приём в лотерею, а ретраи быстро плодят дубли.

Нормальный fan-out начинается с приёма и квитирования: получили payload, проверили подпись, положили событие в надёжное хранилище или очередь, вернули 2xx. Дальше отдельный воркер уже раскладывает событие по подписчикам. Смотрим в тело запроса, но не верим ему на слово:
{"event_id":"evt_123","type":"lead.created","data":{...}}

Ключевые правила: — у каждого события должен быть стабильный event_id; — у каждого получателя свой retry-policy и свой dead-letter; — обработчик обязан быть идемпотентным, иначе после повторной доставки вы получите двойные сделки и тройные письма; — ошибки одного потребителя не должны блокировать остальных. Прокидываем стейт через метаданные, а не через магию в коде.

Если fan-out делать через Nginx/синхронный прокси, он годится только как входной шлюз, но не как диспетчер бизнес-событий. Для развязки используйте очередь, outbox-паттерн или хотя бы таблицу доставки с статусами pending/sent/failed. Иначе ловим 5xx на ровном месте и потом долго объясняем, почему “всё же отправлялось”.

Итог простой: один вход, одно подтверждение, дальше асинхронная доставка по подпискам. Ретрай-политика решает всё, а идемпотентность — это не роскошь, а база.