Webhook Fanout Patterns — A Field Guide

A single event — an order was paid — frequently needs to do several unrelated things: update the ledger, email the customer, notify the warehouse, refresh analytics. Cramming all of that into the webhook handler makes it slow, fragile, and impossible to retry one part without redoing the rest. Fanout separates the one inbound event from the many things it triggers.

Ingest fast, process separately

The first move is to make the webhook endpoint do almost nothing: verify the signature, persist the raw event, publish it to an internal queue or pub/sub topic, and return 2xx. All the real work happens downstream, decoupled from the sender's timeout. The endpoint's only job is to durably accept the event and get out of the way.

One event, many consumers

With the event on a topic, each action becomes an independent subscriber. Pub/sub delivers a copy to every subscriber; each processes at its own pace and retries on its own without affecting the others.

  inbound webhook
        │  (verify, persist, publish, 2xx)
        ▼
   [ order.paid topic ]
        ├──▶ ledger consumer      (own retries, own DLQ)
        ├──▶ email consumer
        ├──▶ warehouse consumer
        └──▶ analytics consumer

The win is isolation. If the email service is down, its consumer retries while the ledger and warehouse consumers carry on. In a single monolithic handler, that same email outage would fail the whole event and force a full re-process.

Keep consumers independent

• Each consumer has its own retry policy and its own dead-letter queue, so one slow or failing action never blocks the others.
• Each consumer is idempotent, because pub/sub is also at-least-once — every subscriber will occasionally see a duplicate.
• Consumers do not depend on each other's ordering or completion; if one action must follow another, chain them explicitly rather than assuming timing.

Fanout turns a brittle, do-everything webhook handler into a fast ingest endpoint plus a set of small, independent, individually retryable consumers. Each action can fail, retry, and scale on its own — and the sender only ever sees a quick acknowledgement.