SQS vs SNS vs EventBridge — Decoupling Patterns for SAA-C03
Choosing between SQS, SNS, and EventBridge is one of the most frequently tested architectural decisions on the AWS SAA-C03 exam. The services look similar but serve different patterns. This page walks through the key decision rules and a representative practice question.
Short answer
The correct answer is B. Have the order service publish to an Amazon SNS topic; each consumer subscribes to the SNS topic.
This scenario describes a fan-out pattern: one event needs to be delivered to multiple independent consumers simultaneously. Amazon SNS is designed exactly for this. The order service publishes a single message to an SNS topic. Each consumer (inventory system, email service, data warehouse) subscribes to the topic and receives its own independent copy. SNS supports multiple subscription protocols: SQS queues, Lambda functions, HTTP endpoints, email, and SMS. Option A is wrong because a standard SQS queue delivers each message to exactly ONE consumer — if three consumers poll the same queue, each message will typically only be processed once by one of them, not all three. Option C introduces unnecessary complexity and polling overhead. Option D creates tight coupling — the order service depends on each downstream service being available, and latency increases with each sequential call.
The Question
A company processes online orders. When a new order is placed, the system must simultaneously trigger an inventory update, send a confirmation email, and log the transaction to a data warehouse. Each of these three systems needs to receive its own copy of the order event. The company wants to minimize coupling between the order service and the downstream consumers. Which architecture should a solutions architect recommend?
Why B is correct
This scenario describes a fan-out pattern: one event needs to be delivered to multiple independent consumers simultaneously. Amazon SNS is designed exactly for this. The order service publishes a single message to an SNS topic. Each consumer (inventory system, email service, data warehouse) subscribes to the topic and receives its own independent copy. SNS supports multiple subscription protocols: SQS queues, Lambda functions, HTTP endpoints, email, and SMS. Option A is wrong because a standard SQS queue delivers each message to exactly ONE consumer — if three consumers poll the same queue, each message will typically only be processed once by one of them, not all three. Option C introduces unnecessary complexity and polling overhead. Option D creates tight coupling — the order service depends on each downstream service being available, and latency increases with each sequential call.
Why the other options are wrong
An SQS queue is point-to-point: each message is delivered to one consumer. Multiple consumers competing on the same queue will each receive different messages, not the same message. For fan-out (one message to many consumers), you need SNS or EventBridge.
DynamoDB Streams can trigger Lambda functions on changes, but this adds unnecessary architectural complexity for a simple fan-out use case. It is not the AWS-recommended pattern for publishing events to multiple consumers.
Synchronous API calls create tight coupling: if any downstream service is slow or unavailable, the order service fails. This violates the decoupling requirement and is the opposite of event-driven architecture.
SQS, SNS, and EventBridge: which to use when
AWS has three main messaging services for decoupling architectures and the SAA-C03 exam tests all three. Understanding the distinctions is essential. Amazon SQS (Simple Queue Service) is a pull-based, point-to-point queue. Producers write messages; consumers poll and process them. Each message is delivered to exactly one consumer (in a standard queue, with at-least-once delivery). SQS Standard queues have unlimited throughput but may deliver messages out of order or more than once. SQS FIFO queues guarantee ordering and exactly-once processing, but have lower throughput (up to 3,000 messages/sec with batching). SQS is ideal for: work queues, background jobs, rate limiting, load leveling. Key words: "process messages one at a time," "retry failed jobs," "decouple producer from consumer rate." Amazon SNS (Simple Notification Service) is a push-based, pub/sub service. One publisher, many subscribers. Each subscriber gets its own copy of the message. SNS supports SQS, Lambda, HTTP/HTTPS, email, and SMS subscriptions. The SNS + SQS fan-out pattern is critical: publish to SNS → SNS pushes to multiple SQS queues → each queue is processed independently. This is the canonical multi-consumer, durable fan-out pattern. Amazon EventBridge (formerly CloudWatch Events) is an event bus with content-based routing. It routes events based on rules that match patterns in the event payload. It natively receives events from 300+ AWS services, SaaS applications, and your own code. Use EventBridge when you need: routing based on event content, integration with third-party SaaS events, scheduled events (cron), or event archiving and replay. The decision tree: one message → one consumer? SQS. One event → many consumers, same message? SNS (or EventBridge). Event routing based on content, AWS service events? EventBridge.
Ready to see how you'd score?
Take the free practice quiz and find out which AWS Solutions Architect Associate domains you need to focus on. No signup required.
Practice 5 similar questions
Same cert, same or adjacent domain. Use these after reviewing the explanation.