The Scenario
Your e-commerce platform emits an OrderCreated event every time a customer places an order. Three separate systems need to react:
- Billing Service — Generate and email a receipt PDF (slow, 10–30 seconds).
- Fulfillment Service — Update the warehouse pick-list database (fast, < 1 second).
- Fraud Detection Service — Score the transaction for risk (critical, must not be skipped).
A naive approach: the Order Service calls all three services sequentially over HTTP. If Billing is slow, the customer waits 30 seconds. If Fraud Detection is down, the order fails entirely.
The Fan-Out Solution
The fan-out pattern uses SNS and SQS together to solve this cleanly:
- The Order Service publishes the
OrderCreatedevent once to an SNS Topic. - Three separate SQS Queues are created — one per downstream service.
- Each queue subscribes to the SNS Topic.
When SNS receives the message, it duplicates and delivers it to every subscribed queue simultaneously. Each downstream service polls its own queue and processes at its own pace. The Order Service returns a success response to the customer immediately after publishing — it doesn't wait for any downstream processing.
Failure isolation is the key benefit: If the Billing service crashes, its SQS queue accumulates messages. When Billing recovers, it drains the backlog. The Fulfillment and Fraud services are completely unaffected — they have their own queues and their own consumers.
SNS Subscription Filter Policies
A powerful but often overlooked SNS feature: Subscription Filter Policies. Instead of every subscriber receiving every message, you can attach a JSON filter policy to a subscription so that a queue only receives messages matching specific attributes.
For example, if your SNS topic receives both OrderCreated and OrderCancelled events, your Fulfillment queue can filter to only receive OrderCreated events, while a separate Refund queue filters for OrderCancelled. This keeps downstream queues clean without requiring the producer to publish to multiple topics.