Amazon SNS is a web service that co-ordinates and manages the delivery of messages to subscribing endpoints or clients. There are two types of clients in Amazon SNS : Publishers & Subscribers. A publisher sends messages to topics that they have created or to topics they have permission to publish to. Instead of including a specific destination address in each message, a publisher sends a message to the topic. Amazon SNS matches the topic to a list of subscribers who have subscribed to that topic, and delivers the message to each of those subscribers.
There are following types of scenarios in which we need to notify our clients :-
Applications and System Alerts : These are simple notifications,triggered by predefined threshold and sent to specified users via mails or sms.There can be many cases which might need to receive immediate notifications when an event such as a specific changes to your AWS scaling group occurs or the disk usage of any specified instance goes beyond the threshold value etc.
Push Emails and Text Messaging : These are the simplest ways to transmit messages to individuals or groups. For example, Amazon SNS could be used to push targeted headlines which includes some exciting offers & discounts corresponding your application to the subscribers. Upon receiving the mail or sms, interested readers can choose to revert you back for the same.
Fanout : The “fanout” scenario is when an Amazon SNS message is sent to a topic and then replicated and pushed to multiple Amazon SQS queues, HTTP endpoints, or email addresses. For example, you could develop an application that sends a message to SNS topic whenever the order is placed for a product. Then, amazon SQS queues that are subscribed to those topic would identically receive notification for the new order.One EC2 instance attached to SQS can fullfill the processing part for the order while the other may perform as a data warehouse to analyze the order received.
Mobile Push Notifications : Mobile push notifications enable you to send notifications directly to mobile applications. You can choose to send notifications on mobile apps when an update is available by directly providing a link to download and install the update.
- Mobile push notifications engage customer when your app is currently not active.
- Users opt in to receive them.
- Delivered to a specific application on a specific device.
- Short messages : read, ignore or acknowledge to launch the app.
So, from a developer’s perspective, when you send a mobile notification you address that message to a particular app on a particular device that you would like to send to and that message is truly sent in a sense that the user doesn’t have to check for and the mobile app doesn’t have to pull from but rather it arrives on the device very quickly and pop up on user’s screen.
In order to maintain this scenario, each mobile device uses a platform service that uses a persistent connection to send messages. So as a developer when you address a message to a device, rather than sending directly to the particular device and rather than maintaining a direct connection to the device, you instead send the notification to a platform service and that platform service relate it to the device. Hence, you don’t have to maintain hundreds or millions of simultaneous connections and you don’t need to hold on to messages in order to deliver them when the device is off.
To implement this scenario, developers manage token for each device and must proactively swap or disable them based on the feedback. This platform service would require you to maintain the list of all the tokens of all the devices you haven’t authorized to send mobile notifications to and when the device is disabled for e.g the user have deleted your app or the token that represents a particular device have been changed, developers are expected to update their databases for these changes so that they can correctly addresses the list of the devices that are allowed.