SAA-C03 Practice Question 15: SNS SQS Fanout

This is the SNS-to-SQS fanout pattern. The order service publishes once to an SNS topic, and SNS pushes a copy of the message to every subscribed queue. Each system then owns its own SQS queue, polls it at its own pace, and deletes messages independently. While billing is down its queue simply accumulates messages, and billing works through the backlog when it returns. The other two consumers are unaffected. SNS supplies the one-to-many delivery, and SQS supplies the durable buffering.

Option A delivers each message to only one consumer. When a system receives and deletes a message, the others never see it, so the three systems would each get a random subset of orders instead of all of them.

Option B gets the fan-out right but loses the buffering. SNS pushes to HTTPS endpoints and retries failed deliveries according to a delivery policy, but the total retry time for an HTTP/S endpoint is capped at 3,600 seconds as a hard limit, so it cannot hold hours of backlog. Events that arrive while billing is offline run out of retries and are dropped unless a dead-letter queue is configured.

Option C still gives each message to a single consumer. A message group ID controls ordering *within* a FIFO queue. It does not copy the message to several readers, and each event would have to be sent three times anyway, which breaks the publish-once requirement.

References: Fanout Amazon SNS notifications to Amazon SQS queues for asynchronous processing; Amazon SNS message delivery retries