Fan-out
The one-to-many pattern where a single event is copied to several downstream consumers, each free to react on its own.
See it
What it is
Fan-out takes one event and delivers a copy to multiple independent destinations. An order-created event might feed fulfillment, email, analytics, and fraud systems without the checkout service calling each one. Amazon SNS topics feeding separate SQS queues are a common concrete version of this shape.
Reach for fan-out when several consumers care about the same fact but must run and fail independently. Give each consumer its own subscription or queue so a slow analytics job cannot block the receipt email. New consumers can then subscribe without changing the publisher.
The multiplier is both the feature and the danger. One publish can become many deliveries, retries, logs, and bills, and a bad event can fail in every branch at once. Put a stable event ID and schema version in the envelope, make each consumer idempotent, isolate dead letters per subscription, and monitor delivery lag separately for every branch.
Ask AI for it
Build an order-created fan-out with one Amazon SNS topic and separate Amazon SQS subscriptions for fulfillment, receipt-email, analytics, and fraud consumers. Publish an envelope containing eventId, eventType, schemaVersion, occurredAt, and the order payload. Give every queue its own retry policy and dead-letter queue, make each consumer deduplicate by eventId, and add CloudWatch alarms for oldest-message age and dead letters on each branch.