2.5 Decoupling with SQS, SNS, and EventBridge
Key Takeaways
- SQS provides point-to-point message queuing with at-least-once delivery; use it to decouple producers from consumers and absorb traffic spikes.
- SNS provides pub/sub messaging that fans out messages to multiple subscribers (SQS queues, Lambda, HTTP endpoints, email).
- EventBridge is a serverless event bus that routes events from AWS services, custom applications, and SaaS partners based on rules.
- SQS Standard queues offer unlimited throughput with best-effort ordering; FIFO queues guarantee exactly-once processing and strict ordering (3,000 messages/second with batching).
- The fan-out pattern (SNS → multiple SQS queues) is the most common decoupling architecture on the SAA-C03 exam.
Decoupling with SQS, SNS, and EventBridge
Quick Answer: SQS = message queue (one producer, one consumer). SNS = pub/sub (one message to many subscribers). EventBridge = event bus (rule-based routing from many sources to many targets). Use the SNS+SQS fan-out pattern for one-to-many reliable message delivery.
Why Decouple?
Tightly coupled systems have a single point of failure — if one component fails, the entire system fails. Decoupling ensures:
- Resilience — Producer and consumer can operate independently
- Scalability — Each component scales independently
- Flexibility — Components can be updated or replaced without affecting others
- Reliability — Messages are not lost when consumers are temporarily unavailable
Amazon SQS (Simple Queue Service)
SQS is a fully managed message queuing service that enables decoupling and scaling of microservices, distributed systems, and serverless applications.
SQS Standard vs. FIFO
| Feature | Standard Queue | FIFO Queue |
|---|---|---|
| Throughput | Unlimited | 3,000 msg/sec (with batching), 300 without |
| Ordering | Best-effort (may be out of order) | Strict FIFO ordering |
| Delivery | At-least-once (possible duplicates) | Exactly-once processing |
| Naming | Any name | Must end in .fifo |
| Use case | High throughput, order not critical | Financial transactions, order processing |
Key SQS Concepts
| Concept | Description |
|---|---|
| Visibility Timeout | Time a message is hidden from other consumers after being received (default 30s, max 12 hours) |
| Long Polling | Consumer waits for messages (up to 20 seconds) — reduces API calls and cost |
| Dead-Letter Queue (DLQ) | Queue for messages that fail processing after N attempts |
| Message Retention | 1 minute to 14 days (default 4 days) |
| Message Size | Up to 256 KB (use S3 for larger payloads via Extended Client Library) |
| Delay Queue | Messages become visible after a delay (0 seconds to 15 minutes) |
SQS + Auto Scaling Pattern
A common exam pattern: SQS queue depth triggers Auto Scaling:
- Messages arrive in SQS queue
- CloudWatch monitors ApproximateNumberOfMessagesVisible
- Auto Scaling adds EC2/ECS consumers when queue depth grows
- Consumers process messages and queue shrinks
- Auto Scaling removes excess consumers
Amazon SNS (Simple Notification Service)
SNS is a fully managed pub/sub messaging service for application-to-application and application-to-person notifications.
SNS Subscriber Types
| Subscriber | Use Case |
|---|---|
| SQS | Fan-out to multiple queues |
| Lambda | Serverless processing |
| HTTP/HTTPS | Webhook notifications |
| Human notifications | |
| SMS | Text message alerts |
| Kinesis Data Firehose | Stream to S3, Redshift, etc. |
| Mobile push | iOS, Android push notifications |
SNS + SQS Fan-Out Pattern (Most Important)
This is the #1 most tested decoupling pattern on the SAA-C03:
- Producer publishes a message to an SNS topic
- SNS fans out the message to all subscribed SQS queues
- Each SQS queue has its own independent consumer
- Consumers process the message at their own pace
Benefits:
- One message triggers multiple independent workflows
- Each consumer can fail independently without affecting others
- SQS queues buffer messages if consumers are slow
- Adding new consumers is as simple as subscribing a new SQS queue
On the Exam: "The application needs to send one event to multiple downstream services for different processing" → SNS + SQS fan-out.
SNS FIFO Topics
SNS FIFO topics pair with SQS FIFO queues for ordered, deduplicated fan-out messaging.
Amazon EventBridge
EventBridge is a serverless event bus that routes events from various sources to targets based on rules.
EventBridge vs. SNS
| Feature | EventBridge | SNS |
|---|---|---|
| Event sources | AWS services, custom apps, SaaS partners | Your applications |
| Routing | Content-based filtering (event patterns) | Topic-based (all subscribers get all messages) |
| Targets | 15+ (Lambda, SQS, Step Functions, API Gateway, etc.) | SQS, Lambda, HTTP, email, SMS |
| Schema | Schema registry and discovery | No schema support |
| Replay | Archive and replay past events | No replay |
| SaaS integration | Yes (Zendesk, Datadog, Shopify, etc.) | No |
When to Use Which
| Scenario | Service |
|---|---|
| Simple queue between producer and consumer | SQS |
| Fan-out one message to many consumers | SNS + SQS |
| Route AWS service events to targets | EventBridge |
| SaaS integration (third-party events) | EventBridge |
| Strict message ordering needed | SQS FIFO |
| Archive and replay events | EventBridge |
An application needs to send a single order event to three different services: an inventory service, a shipping service, and a notification service. Each service must process the event independently. What architecture should be used?
A financial processing system requires messages to be processed in exactly the order they were sent, with no duplicate processing. Which SQS queue type should they use?
What is the purpose of an SQS Dead-Letter Queue (DLQ)?