<b>Один хук на 5 сервисов: как не утонуть в ретраях, дублях и 5xx</b>

<b>Один хук на 5 сервисов: как не утонуть в ретраях, дублях и 5xx</b>

Fan-out выглядит просто: пришёл webhook, дальше разослали полезную нагрузку в billing, CRM, аналитку, нотификации. На практике это не “send all”, а мини-брокер с очередью, квитированием и журналом доставки. Синхронно цеплять всё к одному HTTP-запросу — верный способ ловить 5xx на ровном месте и терять события при первом же падении внешнего API.

Схема рабочая такая: входной хендлер принимает запрос, валидирует подпись, пишет событие в durable storage и сразу отвечает 200. Дальше воркер раскладывает сообщение по подписчикам. Каждый downstream получает свой task_id, а исходный event_id прокидываем через метаданные. Идемпотентность — это не роскошь, а база: повторный webhook не должен создавать второй платёж, второй лид или вторую нотификацию.

Критичные правила:
• один вход → одна запись в журнале
• fan-out только из очереди, не из request thread
• у каждого сервиса свой retry-policy и dead-letter
• частичный фейл не валит весь пайплайн

Если сервис А упал, сервис B не обязан страдать вместе с ним. Разруливаем по статусам, а не по надежде: успешные доставки коммитим, неуспешные уводим в DLQ, потом поднимаем по trace_id. Смотрим в тело запроса и не верим, что внешний API “всегда пришлёт нормальный JSON”.

Вывод простой: fan-out работает только тогда, когда входной хук превращён в событие, а не в цепочку HTTP-импровизаций.