Confused about when to use AWS SNS? Learn through examples in this detailed article.
SNS is a core backend service used to support asynchronous event notifications. It is typically the ‘Pub’ in PubSub – using it, publishers can broadcast messages to many different endpoints (SQS queues, Email, Lambda Functions, and more). This technology has broad reaching applications that help topic owners decouple themselves from consumer clients.
In this blog post, I’m going to teach you the fundamentals of SNS.
Prefer a Video format? Check out my YouTube video here:
What is Amazon SNS
SNS stands for Simple Notification Service, a cloud service offered by AWS. It is a fully managed distributed publish-subscribe system that operates on a Fan-out model. It offers a push notification functionality that lets us send individual messages or bulk messages to a large set of subscribing clients or applications.
The data loss is prevented by storing the data across multiple availability zones. It is cost-efficient and offers a serverless infrastructure. With this, you can send notifications through SMS or email or to an Amazon Simple Queue Service (SQS) or an HTTP endpoint. Primarily it acts as a logical flow access point and as a communication channel between publishers and subscribers.
SNS is the pub in the pub-sub ecosystem
How does it work?
To get started with Amazon SNS, developers must create a topic that acts as an access point for subscribers interested in receiving notifications about a specific theme. Whenever there is an update for subscribers, developers publish a message to the topic through their application, and this move prompts Amazon SNS to distribute the message to all its subscribers simultaneously. The primary need of an SNS is to push a message to multiple subscribers as soon as it receives it from a publishing application.
Amazon SNS allows its users to push messages to various devices based on Windows, Google, Apple, and IoT-based smart devices by using an API or through the AWS console. It is a one-to-many relationship model where we do have a publisher, a topic, and multiple subscribers based on business use cases.
As soon as the publisher is ready to publish on the topic, it acts as a logical unit. We say AWS SNS here will prioritize and push from topic to various available subscribers ranging from one to many. For every message that gets processed to this topic, an identical clone of that message will be delivered to all of these different consumers. These subscribers can be of various forms such as an email, HTTP endpoint, SQS, SMS. Based on the deliverability of SNS, it can be further classified into two types; one is an application to the individual model where any update of the event is needed to notify an individual may be a customer, employee, stakeholder. This would typically happen via the email delivery method.
The other is an application to application model where one application needs to notify the other whenever there is a new event. In this model, applications communicate with eachother to notify one another of changes in their state. We are going to talk about these two more in-depth in a few moments.
Main Features of AWS SNS
- Message Publishing and processing service in simple terms Pub-Sub.
- Allows Fanout to millions of consumers
- Fully managed and durable with autoscaling
- Standard and FIFO topics
- Enables message filtering policy to the topic subscription.
- Works flexibly with both application to person and application to application subscriptions.
Example 1- Application to person
Now, let’s move on to some more practical examples to demonstrate some of the concepts. Assume that you have some kind of online retail business, and you want to send promotional messages to customers that you know about When they came into your store and signed up for an account using their cell phone number.
Task to be performed :
So I have a whole bunch of different cell phone numbers that correspond to these potential customers and want to send a promotional message, maybe once a week. Something promotional like, hey! We’re having a 20% sale; go check out our website.
We go to the AWS console and create a promotion topic, as we have different cell phone numbers for each one. As they have different devices, we need to create a topic that serves on one to many relationship models. The customers who are going to be receiving the messages are subscribers. We have represented the same in the above image.
In the console, you would have three different subscriptions, as represented above by white lines. We want to set off some kind of timer and send a message to our topic, Maybe once every week, just to let our customers know that we’re having the sale.
This timer fires once a week and sends a payload to the topic saying, ” Hey! Customer, We have 20% off on our Website” for this, we only have to create one message and publish that to the topic, and that one message is fan out to all of our different customers that are registered as subscriptions on the SNS topic.
In the above, we are exclusively talking about a scenario where we are sending a single message to multiple subscribers; chronologically speaking, it is too many relationships, but what if you just want to send a message to just customer 3 in the above example?
Using the SMS (a feature of SNS), we can have some application or send a message directly to just customer 3 by leveraging SMS messaging. There are two different adoptions here, one is the one to many fan-out, and then there’s the kind of direct message where you can send something to specific Customers. The best thing is both are possible in the application to person model using AWS SNS.
Now let’s look at the application to application model; how and where can this be implemented?
Example -2 Application to Application model
In this case, we have a customer order topic. For this topic, its theme is whenever a customer order something on a website Site, let’s say we have a customer order service. Whenever a customer places an order, then Nginx or nodejs app will get an API call from the customer and stored in a database for different business applications, such as fraud detection or business intelligence or analytics to enhance the growth.
Task to be performed
Here we need the customer order service to publish a message to the customer order topic. This message would probably contain details about the order that was just taken, maybe the ID, or the amounts, or which store the order was placed at, or if it was online or not. All of these attributes can be included in that simple notification service message. We need this message to be pushed on other AWS services such as Lambda, analytics, SQS.
As similar to what we have done in the previous example, we will do all similar stuff, but in this instance, the SNS message is to be published on different consumers, unlike the previous one where the consumers are software applications and not individuals.
So, as soon as customers order from the store, it publishes a message to the customer order topic. Since many different consumers care about this message, for instance, We have an AWS Lambda function where the infrastructure perspective is handled for you. Through SNS, we can deliver messages to AWS Lambda to scale applications accordingly.
In the next instance, maybe we have a nodejs app dedicated to performing some analytics on the customer order. For this, we can publish SNS topics on other AWS services like redshift to serve analytics.
SQS services are another great AWS option for receiving SNS messages because they get sent to a queue, and messages can be processed from that queue at a later time. Sometimes you don’t need to happen an invocation as soon as the topic is delivered, like as In the case of AWS Lambda and in the nodejs app. So that’s a use case of why you may want to use SQS queues in combination with SNS.
SNS is fully managed, that you don’t need to worry about infrastructure at any time. When you publish a message to SNS from the publisher’s perspective, they don’t guarantee that It’ll be delivered to all of its customers right away. Since there may be chances the consumer devices may not work as expected, or maybe these folks are out of reception, or they have their phones off, So it doesn’t always deliver 100% Percent of the time.
I hope you learned about SNS through these practical examples. Make sure to check out my other blog posts.