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.

How to implement durable fan-out

A durable implementation creates one delivery record per destination before a worker calls any provider. The event is the parent record; each destination is an independently retryable child.

The database contract can be small:

Then create the deliveries and outbox jobs in one transaction:

The unique (event_id, destination_id) key prevents the planner from creating the same logical delivery twice. The transactional outbox prevents a database commit from succeeding while the corresponding queue job disappears. A worker can now claim one delivery, call one destination, and update only that delivery's status.

This separation gives the fan-out system 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

For production workloads, add a claim lease so only one worker owns a delivery at a time, exponential backoff with jitter, and a dead-letter state after the retry budget is exhausted.

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

The build-vs-buy reality

You can build a fan-out system yourself. An event bus, a rule evaluator, per-destination workers, retry tables, dead letter storage, a dashboard—it's all well-understood infrastructure. Most teams estimate a few weeks.

What they underestimate is the ongoing cost: every new destination introduces new auth patterns, new payload shapes, new rate limit behaviors, and new edge cases in error handling. After the third or fourth integration, you're not building product features anymore—you're maintaining a one-off integration platform.

The question isn't "can we build this?" It's "is this where our engineering hours create the most value?"

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.