2.5 Decoupling with SQS, SNS, and EventBridge
Key Takeaways
SQS is a pull-based queue (one message, one consumer) with at-least-once delivery on Standard and exactly-once processing on FIFO.
SNS is push-based pub/sub that fans one message out to many subscribers (SQS, Lambda, HTTP, email, SMS, Firehose, mobile push).
The SNS-to-multiple-SQS fan-out pattern is a core SAA-C03 decoupling architecture: SNS pushes each message to every subscribed queue, and each queue holds it for its own consumer.
SQS FIFO supports 300 msg/sec without batching, 3,000 with batching, and up to 70,000/sec with high-throughput mode in supported Regions.
Key SQS controls: visibility timeout (default 30s, max 12h), message retention (default 4 days, max 14), long polling (up to 20s), and dead-letter queues via maxReceiveCount.
Quick Answer: SQS = pull-based queue, one message consumed once. SNS = push-based pub/sub, one message to many subscribers. EventBridge = serverless event bus with content-based rules and 20+ AWS sources/targets. The SNS → multiple SQS fan-out is the exam's favorite decoupling pattern.
Why Decouple?
In a tightly coupled system, a slow or failed downstream component blocks or breaks the producer. Inserting a queue or bus between them buys resilience (consumer can be down and messages wait), elasticity (each side scales independently), and spike absorption (a queue buffers a burst the consumers drain later). Domain 2 expects you to recognize a coupling problem and reach for SQS, SNS, or EventBridge.
Amazon SQS
SQS (Simple Queue Service) is a fully managed pull queue. Consumers poll for messages, process them, and delete them.
| Feature | Standard | FIFO |
|---|---|---|
| Throughput | Nearly unlimited | 300/s, 3,000/s batched, up to 70,000/s high-throughput |
| Ordering | Best-effort | Strict, per message group |
| Delivery | At-least-once (dupes possible) | Exactly-once processing |
| Name suffix | Any | Must end .fifo |
| Use case | Max throughput | Order/payment processing |
Core controls to memorize:
| Concept | Detail |
|---|---|
| Visibility timeout | Hides a received message from others; default 30s, max 12h |
| Long polling | Wait up to 20s for a message — fewer empty receives, lower cost |
| Message retention | 1 min to 14 days, default 4 days |
| Max message size | 1 MiB (use the Extended Client Library with S3 for larger payloads, up to 2 GB) |
| Dead-Letter Queue (DLQ) | Captures messages exceeding maxReceiveCount |
| Delay queue | Hides new messages 0–15 minutes |
A classic resilient pattern: a CloudWatch alarm on ApproximateNumberOfMessagesVisible drives an Auto Scaling group of consumers up as the backlog grows and down as it drains.
Amazon SNS and the Fan-Out Pattern
SNS (Simple Notification Service) is push-based pub/sub. A producer publishes once to a topic, and SNS pushes to every subscriber.
| Subscriber | Typical use |
|---|---|
| SQS | Durable fan-out to independent queues |
| Lambda | Serverless processing |
| HTTP/HTTPS | Webhooks |
| Email / SMS | Human alerts |
| Kinesis Data Firehose | Archive to S3/Redshift |
| Mobile push | iOS/Android notifications |
The #1 Decoupling Pattern: SNS → multiple SQS
Publish one message to an SNS topic; SNS fans it out to several SQS queues, each with its own independent consumer. Benefits: one event triggers many workflows, each consumer fails or scales independently, queues buffer slow consumers, and adding a new workflow is just adding a subscription. Message filtering on subscriptions lets each queue receive only the events it cares about. SNS FIFO topics pair with SQS FIFO queues for ordered, deduplicated fan-out.
On the Exam: "One event must reach several services that each process it independently" → SNS + SQS fan-out, not one shared queue (a shared queue delivers each message to only one consumer).
Amazon EventBridge
EventBridge is a serverless event bus that routes events by rule from many sources to many targets.
| Feature | EventBridge | SNS |
|---|---|---|
| Sources | AWS services, custom apps, SaaS partners | Your apps only |
| Routing | Content-based event-pattern rules | Topic-based (all subscribers get all) |
| Targets | 20+ (Lambda, SQS, Step Functions, API Gateway, Kinesis) | SQS, Lambda, HTTP, email, SMS |
| Schema registry | Yes | No |
| Archive & replay | Yes | No |
| SaaS integration | Yes (Datadog, Shopify, Zendesk) | No |
Choosing Between Them
- Simple buffer between two components → SQS.
- One message to many independent consumers → SNS + SQS fan-out.
- React to AWS service events or filter by content → EventBridge.
- Third-party SaaS events or replay of past events → EventBridge.
- Strict ordering and dedup → SQS FIFO (with SNS FIFO for fan-out).
Reliability Mechanics That Show Up on the Exam
Decoupling only adds resilience if you tune a few controls correctly.
- Visibility timeout vs. processing time: the visibility timeout must exceed the time a consumer needs to process and delete a message. If processing runs longer, the message reappears and a second consumer processes it again (duplicate work). The fix is to raise the timeout or extend it dynamically with
ChangeMessageVisibility— a very common exam trap ("messages are processed twice"). - Long polling vs. short polling: short polling samples a subset of servers and returns immediately, causing empty receives and extra cost; long polling (
WaitTimeSecondsup to 20) waits for a message, cutting empty responses and API charges. Prefer long polling almost always. - DLQ + redrive: set a DLQ with a
maxReceiveCountso poison-pill messages move aside after N failed attempts; later, redrive them back once the bug is fixed. - Idempotency: because SQS Standard is at-least-once, consumers must be idempotent (safe to process the same message twice). FIFO removes duplicates only within the 5-minute dedup window.
SQS vs. Kinesis, and Ordering Choices
A frequent confusion is SQS versus Kinesis Data Streams. SQS deletes a message once consumed (work-queue semantics, one consumer per message); Kinesis is an ordered, replayable stream where many consumers each read the full record sequence and records persist for up to 365 days. Choose Kinesis for real-time analytics, ordered per-shard processing, and replay; choose SQS for decoupling and load leveling.
| Need | Service |
|---|---|
| Decouple producer/consumer, buffer spikes | SQS Standard |
| Strict order + exactly-once, low/moderate rate | SQS FIFO |
| One event to many independent workflows | SNS + SQS fan-out |
| AWS/SaaS event routing with content filters | EventBridge |
| Ordered, replayable stream for analytics | Kinesis Data Streams |
The recurring exam theme: a single SQS queue gives each message to one consumer; to deliver the same message to many independent consumers you need SNS fan-out or EventBridge, and to keep ordered, replayable history you need FIFO or Kinesis rather than a Standard queue.
An order event must be delivered to three services — inventory, shipping, and notifications — each processing the event independently and at its own pace. Which architecture is correct?
A single SQS queue with three consumers polling it
An EventBridge rule with a single Lambda target
Three separate SQS queues with the producer writing to each one directly
An SNS topic with three subscribed SQS queues (fan-out), one consumer per queue
A payments pipeline must process messages in strict order with no duplicate processing. Which SQS configuration is required?
Standard queue with long polling enabled
Standard queue with a custom sort attribute
FIFO queue, which guarantees ordering and exactly-once processing
Standard queue with a dead-letter queue
What is the purpose of an SQS dead-letter queue (DLQ)?
To archive messages that were processed successfully
To delay delivery of new messages by up to 15 minutes
To encrypt messages at rest
To capture messages that failed processing after exceeding the maxReceiveCount so a poison-pill does not block the main queue
Sections you finish are checked off in the contents.