Intermediate 18 min read

Amazon SNS: Pub/Sub Messaging

By the end of this lesson, you'll be able to:

Explain how SNS's publish/subscribe model differs from SQS's queue model
Explain fan-out and identify a scenario that calls for it
Describe why combining SNS with multiple SQS queues is a common, useful pattern

Prerequisites: "Amazon SQS: Queues"

Publish/subscribe: one message, every subscriber

Amazon SNS (Simple Notification Service) works on a publish/subscribe model. A publisher sends one message to a topic, and SNS delivers a copy of it to every current subscriber of that topic — not just one of them.

Diagram showing a publisher sending one message to an SNS topic, which distributes a copy to SQS queue A, SQS queue B, and another subscriber or target. — This is fundamentally different from SQS: multiple consumers of one queue generally compete for its messages, while every SNS subscriber receives its own copy.

Fan-out: distributing one event to multiple independent processes

This pattern — one event, many interested parties — is called fan-out. Consider an order being completed: billing needs to know about it, analytics needs to know about it, and a notification might need to be sent — three genuinely different, independent pieces of processing, all triggered by the same single event. SNS's publish/subscribe model fits this exactly: publish the event once, and each subscriber does its own thing without knowing or caring what the others are doing.

SNS + SQS: fan-out with buffering per consumer

A very common, useful pattern combines SNS with SQS: publish an event to an SNS topic, and have that topic fan out to multiple SQS queues — one per consumer — rather than the consumers subscribing directly.

Diagram showing an order-created event published to an SNS topic, fanning out to a Billing queue and an Analytics queue, each with its own independent worker. — Combining the two gives fan-out (SNS) plus buffering and failure isolation per consumer (SQS) — a slow or failing Analytics worker never blocks Billing.

Why bother with a queue per subscriber instead of subscribing directly? Each queue gives its consumer the same buffering benefit Lesson 2 described for SQS generally — if the Billing worker is briefly overloaded, its messages simply wait in the Billing queue, with zero effect on the Analytics side. Subscribing a worker directly to SNS without a queue in between loses that buffering.

Not every subscriber type behaves identically

SNS can deliver to more than just SQS queues — Lambda functions and other subscriber types exist too, and this lesson doesn't try to enumerate every one or claim they all behave identically. The concept that matters at a beginner level is the shape (one publish, many subscribers, each independent), not memorizing every subscription type SNS supports.

Exercise

An order-completed event needs to independently reach a Billing process and an Analytics process, and each should be able to buffer its own work if temporarily busy. Using this lesson's pattern, describe the architecture you'd use (naming the specific AWS services involved), and explain why subscribing the Billing and Analytics workers directly to an SNS topic (with no queue in between) would lose an important property this scenario needs.

Show hint

The architecture is SNS fanning out to two separate SQS queues; the property lost without a queue is buffering.

Amazon SNS: Pub/Sub Messaging Quiz

1. An order event must independently reach both a Billing process and an Analytics process, and each should buffer work if temporarily busy. Which pattern best fits?

An SNS topic fanning out to two separate SQS queues, each with its own consumer A single SQS queue that both Billing and Analytics read from A direct call from the order service to both Billing and Analytics Storing the event only in S3 for later manual review

2. SNS and SQS are interchangeable services.

True False

My Notes

Questions about this lesson

No questions yet — be the first to ask.

Summary

Amazon SNS distributes one published message to every current subscriber of a topic — fundamentally different from SQS, where multiple consumers of the same queue generally compete for its messages rather than each receiving a copy — and combining SNS with several independent SQS queues is a common pattern for fanning a single event out to multiple consumers that should each process it on their own schedule.

❬ Previous Next ❭