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

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

Fan-out выглядит просто: приняли один webhook, дальше разослали событие в CRM, биллинг, нотификации и аналитику. Проблема начинается там, где один и тот же payload уходит в несколько хендлеров с разной скоростью, разной надежностью и разными требованиями к схеме. Если это делать напрямую из HTTP-потока, вы получаете зависимость от самого медленного получателя и ловите 5xx на ровном месте.

Нормальная схема: входной endpoint только валидирует подпись, кладет событие в durable-очередь и сразу отвечает 2xx. Дальше отдельный dispatcher читает событие, раскладывает его по подписчикам и фиксирует состояние доставки по каждому consumer’у. Прокидываем стейт через метаданные: event_id, source, attempt, trace_id. Идемпотентность — это не роскошь, а база, потому что повторная доставка после таймаута — не баг, а стандартный режим жизни.

Если сервисов несколько, у каждого должен быть свой retry-policy и свой DLQ. Один consumer упал — не стопорим остальных. Плохая практика: один общий ретрай на весь fan-out, где ошибка в нотификациях блокирует бухгалтерию. Хорошая: per-destination backoff, ограничение по попыткам и отдельный разбор ядовитых сообщений. Смотрим в тело запроса: если payload не проходит schema validation, не ретраим бесконечно, а сразу уводим в карантин.

Минимальный контракт для такого пайплайна: `event_id` уникален, доставка по каждому получателю фиксируется отдельно, обработчик умеет принимать дубликаты, а входной сервис не ждет синхронных ответов downstream. Тогда fan-out остается маршрутизацией событий, а не лотереей.