Decoupling with queues, topics and events
Loosely coupled systems keep working when one component slows down or fails, and each part can scale independently. Task statement 2.1 tests this directly, and "decouple" in a question almost always points to the services in this chapter.
Tight vs loose coupling
- Tightly coupled: the web tier calls the order service synchronously; if the order service is slow or down, the website fails too.
- Loosely coupled: the web tier puts an order message on a queue and returns immediately; workers process messages at their own pace. Spikes are absorbed by the queue.
Amazon SQS (Simple Queue Service)
A fully managed message queue. Producers send messages; consumers poll, process, then delete them.
| Standard queue | FIFO queue | |
|---|---|---|
| Throughput | Nearly unlimited | High, but limited per queue (higher with batching and high-throughput mode) |
| Ordering | Best effort | Strict order within a message group |
| Delivery | At least once (occasional duplicates) | Exactly-once processing (deduplication) |
| Use | Most decoupling | Order-sensitive workflows (financial transactions, sequential commands) |
Key settings:
| Setting | Meaning |
|---|---|
| Visibility timeout | How long a received message is hidden from other consumers while being processed (default 30 s, max 12 h). Set longer than processing time, or duplicates appear |
| Message retention | 1 minute to 14 days (default 4 days) |
| Long polling | Wait up to 20 s for messages — fewer empty responses, lower cost |
| Delay queues / message timers | Postpone delivery up to 15 minutes |
| Dead-letter queue (DLQ) | Messages that fail repeatedly (max receive count) move here for inspection |
| Message size | Kept small; for large payloads, store the data in S3 and send a reference (the SQS Extended Client pattern) |
Scaling consumers: Auto Scaling groups or ECS services scaled on queue depth / backlog per worker; Lambda can poll SQS directly with automatic scaling.
Amazon SNS (Simple Notification Service)
Publish/subscribe: a publisher sends a message to a topic; SNS pushes it to every subscriber — SQS queues, Lambda, HTTP/S endpoints, email, SMS, mobile push, Kinesis Data Firehose.
- Message filtering — subscribers receive only messages matching their filter policy.
- FIFO topics — ordering and deduplication, delivering to SQS FIFO queues.
Fan-out pattern
┌──► SQS: inventory-queue ──► inventory service
Order placed ──► SNS topic ─┼──► SQS: shipping-queue ──► shipping service
└──► SQS: analytics-queue ──► analytics
Each service gets its own durable queue and processes independently. A very common exam answer for "send the same event to several systems reliably".
SQS = queue (one consumer group pulls; buffering, load levelling). SNS = topic (push to many subscribers). SNS + SQS = fan-out with durability.
Amazon EventBridge
A serverless event bus for event-driven architectures:
- Receives events from AWS services (e.g. EC2 state change, S3 object created), your applications and SaaS partners.
- Rules match events by content and route them to targets (Lambda, Step Functions, SQS, SNS, API destinations, other buses — over 20 target types).
- Scheduler — cron-style and one-time schedules at scale.
- Archive and replay events; schema registry.
- Pipes — point-to-point integration from sources (SQS, Kinesis, DynamoDB Streams) to targets with filtering and enrichment.
Cue: "react to events from many AWS services or SaaS apps with content-based routing" → EventBridge.
Amazon MQ
Managed Apache ActiveMQ and RabbitMQ brokers supporting standard protocols (AMQP, MQTT, STOMP, OpenWire, JMS).
Cue: "migrate an existing application that uses JMS/AMQP/MQTT messaging without rewriting code" → Amazon MQ. For new cloud-native apps, prefer SQS/SNS.
Amazon AppFlow
Fully managed, no-code data flows between SaaS applications (e.g. Salesforce, ServiceNow, Slack, Zendesk) and AWS services such as S3 and Redshift — with filtering and transformation. Cue: "regularly copy Salesforce data into S3 for analytics, no custom code".
Choosing
| Need | Service |
|---|---|
| Buffer work, absorb spikes, decouple producer from one consumer group | SQS |
| Strict ordering and no duplicates | SQS FIFO |
| Broadcast to many subscribers / notifications | SNS |
| Same event to multiple services durably | SNS → multiple SQS (fan-out) |
| Route events from AWS services/SaaS by content; schedules | EventBridge |
| Existing JMS/AMQP/MQTT app | Amazon MQ |
| Multi-step workflows with state, retries | Step Functions |
| Real-time stream with replay and multiple readers | Kinesis Data Streams (next chapter) |
| SaaS ↔ AWS data sync | AppFlow |
Exam patterns
- "Orders are lost when the processing service is down" → SQS between web tier and processors.
- "Process orders exactly in the order received" → SQS FIFO.
- "Notify email, SMS and a Lambda function when an alarm fires" → SNS.
- "Messages fail repeatedly and block processing" → dead-letter queue.
- "Run a job every night at 2 a.m. serverlessly" → EventBridge Scheduler → Lambda/Step Functions.
Senior Full-Stack Engineer · AI & AWS. I design and run production systems on AWS — serverless, data and AI.