2.5 Decoupling with SQS, SNS, and EventBridge

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.

Core controls to memorize:

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.

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.

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 (WaitTimeSeconds up to 20) waits for a message, cutting empty responses and API charges. Prefer long polling almost always.
• DLQ + redrive: set a DLQ with a maxReceiveCount so 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.

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.