What's changed: In-scope service coverage (axis B): added Kinesis Data Streams streaming definition, role, and selection vs SQS/SNS/Firehose to s2 (EventBridge).
2.1Loose Coupling with SQS and SNS
Understand loose coupling: SQS (point-to-point, pull) vs. SNS (pub/sub, push), visibility timeout, dead-letter queues, and fan-out.
Putting messages between components instead of direct calls keeps a failure in one from cascading. On AWS the staples are SQS (queue) and SNS (pub/sub).
2.1.1SQS and SNS
- SQS: a queue; a consumer pulls and processes a message once. Good for absorbing spikes and async work.
- SNS: pub/sub; publishing to a topic pushes to multiple subscribers (fan-out).
- Visibility timeout: how long an in-flight message is hidden; too short causes double processing, too long delays retries.
- Dead-letter queue (DLQ): isolates messages that fail a set number of times for inspection/reprocessing.
- Standard vs FIFO: standard = high throughput, best-effort order, at-least-once; FIFO = strict order, deduplication (exactly-once processing).
Direct calls between components cascade failures and overload. Loose coupling via messaging is the key to resilience and scale. SQS (queue) means "buffer and process once reliably"—a consumer pulls, the message is hidden by the visibility timeout until done, and repeated failures go to a DLQ. SNS (pub/sub) pushes one publish to many. Combining them as fan-out (SNS topic → multiple SQS queues) delivers the same notification to several processors, each buffering and retrying independently—a classic pattern. For ordering/dedup, choose a FIFO queue.
| Aspect | SQS | SNS |
|---|---|---|
| Model | Queue (1:1) | Pub/sub (1:many) |
| Delivery | Pull | Push |
| Main use | Buffer/async work | Notify/fan-out |
| Features | Visibility TO, DLQ, FIFO | Topics, subscriptions |
Scenario: async order processing. Buffer orders in SQS to absorb peaks; workers (Lambda/Auto Scaling) process at their pace. Messages that keep failing go to a DLQ for inspection. Publish the "order placed" event to an SNS topic and fan out to separate SQS queues for inventory, billing, and email—processed in parallel. Use a FIFO queue where payment ordering matters.
Watch the mix-ups: (1) SQS = pull, 1:1 / SNS = push, 1:many. (2) Visibility timeout: too short = double processing / too long = delayed retries—match it to processing time. (3) A DLQ isolates failed messages (it doesn’t delete them). (4) Standard (best-effort order, at-least-once) vs FIFO (strict order, dedup).
Q. SQS or SNS? Buffer and process once = SQS; one publish to many = SNS; combine via fan-out (SNS → multiple SQS). Q. Visibility timeout? Time an in-flight message is hidden—set it longer than processing time. Q. Standard vs FIFO? Standard is high-throughput but best-effort order, at-least-once; FIFO gives strict order and dedup (exactly-once processing).
Common on DVA: process-once, pull = SQS, push 1:many = SNS, deliver to many at once = SNS fan-out (SNS→multiple SQS), isolate failed messages = DLQ, ordering/dedup = FIFO queue, hide in-flight = visibility timeout.
2.1.2Section summary
- SQS = queue (pull, 1:1, buffer) / SNS = pub/sub (push, 1:many, fan-out)
- Know visibility timeout, DLQ, and standard/FIFO (ordering/dedup)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Which is a pull-based queue where one consumer retrieves and processes a message?
Q2. You want to push one message to multiple subscribers at once. What do you use?
Q3. In SQS, what isolates repeatedly failing messages for later inspection?