Один webhook на три сервиса — без очереди и хаоса, если сделать fan-out правильно

Один webhook на три сервиса — без очереди и хаоса, если сделать fan-out правильно

Fan-out — это когда один входящий хук не “обрабатывается”, а раскладывается по нескольким потребителям: CRM, аналитика, нотификации, антифрод. Наивная схема «получили JSON → дернули 3 API» выглядит просто ровно до первого 500 от внешнего сервиса. Дальше начинается магия потерь, дублей и ночного дебага.

Правильный хендлер делает только три вещи: валидирует подпись, пишет payload в durable storage или очередь, возвращает 2xx. Всё остальное — асинхронно. Пример шины:
{
"event_id": "evt_123",
"source": "billing",
"payload": {...},
"targets": ["crm","analytics","notify"]
}

Дальше каждый consumer читает свою копию и живет отдельно. У CRM свой ретрай-политика, у аналитики свой batch, у уведомлений свой rate limit. Сервис упал — падает только он, а не весь пайплайн. Идемпотентность — это не роскошь, а база: event_id, dedup-key, хранение статуса доставки. Иначе fan-out превращается в fan-out дублей.

Если нужен порядок, не пытайтесь склеить его магией HTTP. Прокидываем стейт через метаданные, ставим DLQ для ядовитых событий и отдельно мониторим lag по каждой ветке. Смотрим в тело запроса, а не в надежду на “авось пронесет”.

Итог простой: fan-out работает только тогда, когда входящий хук быстро квитируется, а распределение живет в очереди, а не в синхронных дерганьях внешних API.