From One Event to Many Integrations: A Practical Guide to Fan-Out Architecture

This works until:

• one destination is slow (your handler is now slow)
• one destination is flaky (you need retries with exponential backoff and jitter)
• each integration wants different payload shapes
• you need per-tenant configuration ("ACME wants this, Contoso wants that")

You quickly end up with:

• per-integration branching (if tenant === 'acme' then ...)
• mixed concerns (business logic + integration plumbing)
• tangled retries and error handling

Promise.allSettled is safer than Promise.all when you need every request to finish, but it only isolates failures inside one running process. It does not survive a crash, preserve retry state, or tell you which destination still needs work after the request ends.

Pattern: central event + external fan-out

A more robust pattern:

1. Your core app emits a single, clean event.
2. A dedicated integration layer receives the event.
3. The integration layer:
   • evaluates rules
   • decides which destinations should receive it
   • maps the payload
   • handles retries, backoff, and dead letters

Your app code stays focused on business events, not integration details.

For a deeper walkthrough of how routing rules determine which data goes where, see our post on event routing for SaaS.

What durable fan-out requires

The pattern above only works if each destination has its own delivery state. The event is the parent record; each destination is an independently retryable child with its own status, attempt count, next-attempt time, and last error.

That one decision pulls a lot of machinery in behind it:

• a delivery record per event and destination, with a uniqueness guarantee so a replanned event never produces the same delivery twice
• a transactional handoff between "deliveries planned" and "jobs queued", so a database commit cannot succeed while the matching queue job disappears
• a claim lease so only one worker owns a delivery at a time
• backoff with jitter tracked per delivery, not per event
• a dead-letter state once the retry budget is exhausted, and a replay path out of it

Get all of that right and the fan-out system has the properties that matter:

• one slow destination cannot hold the parent event open
• retries target only the failed destination
• successful siblings remain successful
• every attempt can use the stable delivery identity as an idempotency key
• per-tenant routing changes stay in destination and rule data, not app code

Each item on the first list is a subsystem your team operates alongside the product, and each one has its own failure modes when a worker dies mid-flight.

A concrete example

Your app just does this:

Everything else (CRMs, webhooks, Slack, etc.) is configured as rules in the integration layer.

Why event fan-out belongs outside your core app

1. Different destinations fail differently

• CRMs might rate-limit or return 429s.
• Webhooks might timeout or be misconfigured.
• Analytics endpoints might be slow but not critical.

The customer UI needs to return fast, so it can't wait for these things to happen.

You don't want your core app to decide, per destination:

• what's retryable
• how long to backoff
• when to give up
• how to store dead letters

An integration layer can centralize that logic and treat each destination appropriately. When delivery does fail permanently, you need a dead letter queue to catch and replay events—not a silent data loss.

2. Per-tenant customization explodes combinatorics

Imagine:

• 1,000 customers
• each with their own preference of:
  • which CRM to use
  • which fields to map
  • which events they care about

Baking that into your app produces a mess of:

Versus:

• one event schema per event type
• per-workspace rules + mappings in the integration layer

This is the multi-tenant integration pattern: workspaces isolate each customer's credentials, rules, and delivery state so one tenant's configuration never affects another.

3. Observability becomes manageable

Instead of:

• grepping app logs for "hubspot failed"
• trying to correlate job IDs with webhook IDs

You get:

• one place to see an event and all downstream attempts
• per-destination status and error messages
• retry and dead-letter counts

Implementing fan-out with Meshes

Meshes is designed to be that integration layer:

• Events – you POST events into the API.
• Rules – you configure routing, conditions, and destinations.
• Connections – you securely store OAuth/API keys per workspace.
• Delivery engine – you get fan-out, retries, and dead letters out of the box.

Your architecture becomes:

1. App: emit lead.created.
2. Meshes:
   • match rules on lead.created
   • fan-out to HubSpot, Salesforce, webhooks, etc.
   • manage retries and failures

You keep one clean pipeline:

Domain events in → integrations out.

When to adopt fan-out architecture

You'll get the most value when:

• you're integrating with more than a couple of third-party services
• customers are asking for per-tenant integration behavior
• you're spending time debugging "where did this webhook go?"

If you're already there, it might be time to centralize event fan-out instead of bolting on another webhook handler in your core app.

That's exactly the job Meshes is trying to do for you.

Ready to centralize your fan-out? Join Meshes and route events to every destination from one API.