In the previous subchapter we saw SQS, where a message goes to one consumer who processes it. But sometimes you want the opposite: for the same message to reach many recipients at once. That's what SNS (Simple Notification Service) is for, AWS's notification service. It's the perfect complement to queues.

Imagine that an order is placed in a store, and when that happens you want several systems to find out at the same time:

• The billing service (to generate the invoice).
• The inventory service (to deduct the stock).
• The emails service (to notify the customer).
• The analytics service (for statistics).

With an SQS queue, the message would go to one consumer. Here we want the notification "there is a new order" to reach all at once. That's exactly what SNS does.

SNS works with the publisher/subscriber (pub/sub) model:

• A publisher sends a message to a topic.
• All subscribers to that topic receive a copy of the message, at the same time.

• Topic: the "channel" to which messages are sent (e.g. new-order).
• Subscription: each recipient subscribes to the topic to receive its messages.

Analogy: SNS is like a broadcast list or a radio channel. The announcer (publisher) broadcasts a message once, and everyone subscribed to the channel receives it simultaneously. The announcer doesn't need to know how many listeners there are or who they are.

It's essential not to confuse them:

In summary: SQS distributes work (one message, one worker); SNS broadcasts notifications (one message, everyone is informed).

An SNS topic can have many types of subscribers, making it very versatile:

• A Lambda function (to react to the event, Chapter 14).
• An SQS queue (very important! we'll see it in a moment).
• An email (SNS sends an email).
• An SMS (a text message to a mobile phone).
• An HTTP/HTTPS endpoint (notify another system via web).

Here is the most powerful combination, and one of the most used architectures in AWS: the fan-out pattern. It consists of placing an SNS topic that broadcasts to several SQS queues, one for each service.

Why is it so good to combine them? Because it combines the best of both:

• SNS broadcasts the notification to all services at once (one to many).
• Each SQS queue gives its service the resilience and buffering we saw in subchapter 15.1: if the inventory service goes down, its messages wait in its queue without being lost, while the other services continue to function normally.

Real world example: in the store, "new order" is published to the SNS topic. It instantly reaches the billing, inventory, emails, and analytics queues. The analytics service is under maintenance (down), but its messages accumulate in its queue and will be processed when it comes back. Meanwhile, billing, inventory, and emails process theirs without issue. No order is lost and no service blocks the others.

This fan-out pattern is the basis of many event-driven architectures (we'll see it in subchapter 15.4 and in Chapter 28).

• SNS is the notification service with a publisher/subscriber model: a message sent to a topic reaches all its subscribers at once (one to many).
• Key difference with SQS: SQS distributes work (one message → one consumer); SNS broadcasts notifications (one message → all subscribers). Like a broadcast list or a radio channel.
• Subscribers can be Lambdas, SQS queues, emails, SMS, or HTTP endpoints.
• The fan-out pattern (SNS → several SQS queues) combines the best of both: broadcast to all services + resilience and buffering of each queue. It's one of the most used architectures.

In the next subchapter we'll see a more modern and flexible event service that expands on these ideas: EventBridge.