What is Fan-out Routing in Slashbin?

Fan-out Routing is delivering a single inbound webhook to multiple destinations simultaneously, each through its own Destination Model. Every destination has independent filters, retries, circuit breakers, and dead-letter handling, so a failure in one does not affect any other.

Why fan out at the gateway instead of in my own code?

Fanning out in your own code couples destinations together: one slow API blocks the others, one outage backs up the queue, and retry logic has to be rebuilt per destination. Fanning out at the gateway gives every destination its own pipeline — independent retries, independent backpressure, independent DLQ — without any of that being your problem.

Can I filter which destinations receive a given webhook?

Yes. Each destination has its own filter rules evaluated against the Golden Model record. You can send subscription orders to your CRM only, route high-value orders to a Slack channel, or skip analytics for test traffic — each filter is independent.

What happens when one destination is down?

Only that destination is affected. Its per-destination circuit breaker opens, failed deliveries land in its dedicated DLQ, and retries follow its own backoff schedule. Deliveries to every other destination continue normally with no shared queue, no shared rate limit, and no shared retry storm.

Is the inbound webhook duplicated for each destination?

Logically yes, operationally no. The inbound payload is stored once. Each destination's delivery is tracked independently — its own attempt history, its own status, its own retry state — but they all reference the same original webhook record, so replay is always faithful to what the vendor actually sent.

Fan-out Routing

Fan-out Routing delivers one inbound webhook to many destinations at the same time. Each destination has its own Destination Model, its own filters, its own retry behavior, and its own dead-letter queue. A failure or outage in one destination has zero effect on any other — no shared queue, no shared rate limit, no shared retry storm.

Why use Fan-out Routing?

Most webhook pipelines start with one destination. By month three, you need three: your CRM, your warehouse, and your analytics tool. If you fan out in application code, three things go wrong:

Failure couples destinations. A slow analytics API holds up the request, the warehouse times out, and you start dropping deliveries to everything.
Retry logic gets duplicated and inconsistent. Each destination needs its own backoff, its own circuit breaker, its own DLQ — and you re-implement all of it for each one.
Adding a destination means writing code. Marketing wants Klaviyo. Now it's a deploy.

Fanning out at the gateway makes destinations independent by construction. Each one is its own pipeline. Adding a destination is configuration, not code. And one destination going down stays one destination going down.

How it works

When a webhook arrives, it's validated against the Golden Model once. Then each configured destination runs its own filter, applies its own Destination Model mapping, and delivers through its own retry-and-DLQ pipeline.

graph TD
  S["Inbound Webhook"] --> G["Golden Model\n(validated once)"]
  G --> F1{"Filter: Analytics"}
  G --> F2{"Filter: Fulfillment (Dev)"}
  G --> F3{"Filter: Fulfillment (Prod)"}
  F1 -->|pass| DM1["Destination Model"]
  F2 -->|pass| DM2["Destination Model"]
  F3 -->|pass| DM3["Destination Model"]
  DM1 --> D1["Analytics"]
  DM2 --> D2["Fulfillment (Dev)"]
  DM3 --> D3["Fulfillment (Prod)"]
  D1 -.->|on failure| DLQ1["DLQ: Analytics"]
  D2 -.->|on failure| DLQ2["DLQ: Dev"]
  D3 -.->|on failure| DLQ3["DLQ: Prod"]
  style G fill:#a855f7,color:#fff
  style D1 fill:#7c3aed,color:#fff
  style D2 fill:#7c3aed,color:#fff
  style D3 fill:#7c3aed,color:#fff

Three deliveries from one inbound webhook. If Fulfillment (Prod) is down, only its circuit breaker trips. Analytics keeps flowing. Fulfillment (Dev) keeps flowing. When the production endpoint recovers, you retry its DLQ — the original payload is replayed exactly as the vendor sent it.

Example

A slashbin customer's fulfillment-routing pipeline ingests order webhooks from a single Shopify source. The fan-out delivers to three destinations:

Analytics — every order, full Golden Model payload, fire-and-forget.
Fulfillment (Dev) — only orders tagged staging, mapped to the warehouse's test API.
Fulfillment (Prod) — production orders only (filter: tags does not contain "staging"), mapped to the warehouse's production API.

Each destination has its own Destination Model and its own filter. Last quarter the production warehouse had a four-hour API outage. Analytics and Dev fulfillment continued without interruption. When production recovered, the customer retried the production DLQ and every missed order delivered cleanly — no duplicate orders, no lost orders, no manual reconciliation.

Related concepts

Golden Model — the canonical schema validated once before fan-out, so every destination sees consistent data.
Destination Model — the target-shaped schema each destination uses, derived from the Golden Model.
Replay & Retry — how the per-destination DLQ replays original payloads to recover from outages.

Destination Model Shopify: Onboard Webhooks