Fan-out

Fan-out is delivering one event to multiple consumers in parallel. A payment_failed webhook might trigger a recovery agent, update the billing database, post to a Slack channel, and update an analytics dashboard — all from the same source event.

In webhook systems, fan-out happens at one of two layers:

• At the relay — some systems create multiple deliveries from one incoming event, one per consumer.
• At a downstream broker — the relay delivers to a single broker (SNS, EventBridge, Kafka), which fans out to internal consumers.

Hooksbase v1 does routing, not relay-level fan-out: priority-ordered rules select one destination for each event, with a default destination as the fallback. To fan out one Hooksbase delivery to multiple consumers, route it to a downstream broker or to an HTTP destination that owns that fan-out.

When to fan out at the relay vs at the broker

Fan-out at the relay is the right answer when your relay supports it and:

• The destinations are heterogeneous (HTTP endpoint, SQS queue, S3 bucket)
• The fan-out is cross-system (your customer's endpoint, your internal queue, an audit log)
• You want one queryable delivery history per destination

Fan-out at a broker is the right answer when:

• The destinations are all internal AWS services (SNS subscribers, EventBridge targets)
• You need per-consumer offset tracking (Kafka consumer groups)
• The throughput exceeds what HTTP delivery can comfortably handle

For most Hooksbase agent systems today, choose a single destination with routing rules, or hand off to a broker when multiple consumers must process the same event.

For the design framework: Routing, transforms, and replay for AI agents.