Amazon SNS
SNS (Simple Notification Service) is a pub/sub messaging service where a single message published to a topic is delivered to every subscriber simultaneously — unlike SQS, where each message goes to exactly one consumer. Subscribers can be SQS queues, Lambda functions, HTTP endpoints, email, or SMS, and publishers never need to know who's subscribed, letting you add new consumers without changing the producer.
At a food-delivery company, the Order Service publishes once to an order-events SNS topic, and the fraud, shipping, email, and analytics teams each subscribe an SQS queue to it independently — adding a new downstream consumer never touches the Order Service's code.
The Fan-Out Pattern
SNS alone doesn't persist messages — if a subscriber is down, that message is lost. Subscribing an SQS queue to the topic (instead of a service directly) adds durability: the queue holds the message until the consumer is back up.
Message Filtering
Filter policies let each subscriber receive only the messages it cares about — e.g. a refund queue can subscribe with a filter for {"status": ["cancelled"]} while everything else is ignored.
RememberSNS email is plain text with no formatting or delivery tracking — fine for internal ops alerts, wrong for transactional customer emails. Use SES for those.
Frequently Asked Questions
How does SNS fan-out actually work in a real architecture?
A single event — say, 'order placed' — gets published once to an SNS topic, and SNS delivers a copy to every subscriber independently: an SQS queue for the fulfillment service, another SQS queue for the analytics pipeline, a Lambda for sending a confirmation email, all at once. This is the classic SNS+SQS fan-out pattern — it decouples the publisher from consumers entirely, so adding a new downstream service is just adding a new subscription.
What's a common mistake when using SNS?
Subscribing an HTTP endpoint directly to SNS without a retry/dead-letter strategy — if that endpoint is briefly down, SNS retries with backoff but eventually drops the message, silently losing it. The safer pattern is subscribing an SQS queue instead of an endpoint directly, since SQS persists the message durably until a consumer processes it, and configuring a dead-letter queue for messages that repeatedly fail.