The communication model of SNS is one-to-many 1:N; each time a message gets published to the topic, the service is responsible for the delivery of the message to every one of the subscribers available:
In the preceding diagram, we have subscribed a Lambda function, an SQS queue, and an external server via an HTTPS endpoint, and a mobile application via vendor push messaging and email.
Messages will be delivered to all the channel's subscribers, and subscribers who arrive late will lose their sent messages. This kind of messaging is excellent for orchestrating communications between microservices, and every listening party chooses to process the message of drop it.
Once a message has been sent, it cannot be sent again, and this is because SQS is not persistent, as the service only acts as a message relay with the ability to scale up to trillions of messages per second.
The available subscribers are as follows:
Subscriptor |
Use case |
Amazon SQS |
Fanout |
Application |
Push messaging for mobile devices |
|
Human-intended communication |
Email/JSON |
Application processing via email |
HTTP/HTTPS |
Webhooks |
Lambda function |
Serverless processing and real-time |
SMS |
Mobile phones without push capabilities, 2FA authentication |
This summary can help you decide the best use case for every kind of subscription available for SNS.