Subscriber

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

Email

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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.218.171.212