Difference Between Amazon SNS vs SQS – When To Use What?

Many modern applications are being built using serverless technologies. The underlying architecture typically uses a combination of different AWS services for message coordination and asynchronous communication between components.

SNS and SQS are two important services that help decouple applications and allow for asynchronous message communication.

In this blog, I am going to talk about the difference between Amazon SNS and SQS. I am going to introduce you to both of the services in-depth, compare them, and clarify the difference using a practical example.

Let’s get started.

Prefer video format? Check out my YouTube video on this topic.

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. It offers a push notification functionality that lets us send individual messages or bulk messages to a large set of subscribing clients or applications.

SNS is the pub in pub-sub.

The core functionality of Amazon SNS is to push a message to multiple subscribers as soon as it receives it from a publishing application.

To get started with Amazon SNS, developers first have to 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.

It makes it simple and super cost-effective to send push notifications to mobile users across distributed devices such as Android, Apple, Windows, email recipients and other internet-connected devices. Supports several endpoints such as email, SMS, HTTP endpoint and SQS.

SNS can also integrate directly with other AWS services – a popular one is AWS Lambda.

What is Amazon SQS

SQS stands for Simple Queue Service, a cloud service offered by AWS. It is a fully managed message queuing service that offers a secure, durable and available hosted queue, and it lets us integrate and decouple distributed software systems and components. Unlike SNS, messages are not pushed to receivers. Instead, receivers need to Poll SQS to receive messages.

Polling, to put it simply, is the act of a subscriber application continuously asking your SQS queue for messages (even when none may be available). When one IS available, your poller will hand off the message to your application code to process the message.

There are many libraries that make polling easier including the AWS SQS SDK.

When polling for a message, SQS has a feature that makes it so that multiple threads from a polling application do not double-process a message. Once a message is polled, it is claimed by the thread for a period of time. During this period, the message is invisible to all other threads. The thread that acquired the message needs to process and delete the message from the queue to indicate it is done processing. Otherwise, the message is returned back to the queue (or optionally sent to a Dead Letter Queue) for another attempt.

Amazon SQS operates on both Standard and FIFO Queue principles; standard queues offer maximum throughput and guarantee at-least-once delivery, FIFO queues are designed to guarantee that messages are processed exactly once, in the same order they are sent.

SNS vs SQS- Tabular Comparison of Amazon SNS & SQS

A Practical Example

Let’s talk about a practical example now. In this example, we’re going to be talking about credit card transactions where we have a user, and they are making a purchase on some website or through some POS terminal and putting in their credentials to buy some kind of product.

Now they’re making a purchase request to some kind of REST API, and we’re just calling this a transaction processing web service, and the payload of it may looks something like this-

You need to first communicate with some kind of credit card authority service, practically speaking, probably Visa, Mastercard, Amex, etc. So when an event occurs saying that a transaction is taking place, that should get validated against the authority to ensure the transaction is authenticated.

When step 1 is successfully passed, then there might be relevant subsystems in the ecosystem which may publish this event to a Transaction SNS topic, and from this topic, there can be multiple different subscribers with all narrow use cases, so in this example, I have three different ones. I have a lambda, and I have two SQS.

The important bit to understand is that these subscribing applications are completely decoupled from one another, and also decoupled from the publishing application. This is the strength of using SNS.

Use Case of Lambda

When a message gets delivered, maybe we have some kind of customer reminder service, and if you’ve ever ordered anything online, maybe on Amazon or any kind of web site you know that when you order something shortly after that, you get an email that says something like “thank you for ordering, we really appreciate your interest and here’s a summary of purchase”.

This component is responsible for that very handy information your customer receives very often. In the back end, whenever there is a message received from the Transaction SNS topic, it invokes the lambda function which sends an email to your customer automatically.

There are two other subsystems here that care about these same events, but they do very different things. Let’s take a look.

Use case of 1st SQS Subscriber – Analytics

This system with SQS as queue could be some kind of analytics engine, so when an event occurs, in addition to publishing to this lambda function, the topic is publishing that same event to an analytics queue. This system may be one of its responsibilities is it cares about how many orders are generated in a single day, or maybe you want to show that on a dashboard.

When an event occurs, this payload gets delivered to this queue. It’s not going to really do anything; you need another system here to poll the queue to actually become aware that something is in there and respond to it. In this example, we configured some transaction analytic services hosted on ec2 and part of spinning up your service. It will have a series of polling threads that know to pull messages off of this queue, and when there is a relevant value, it increments the count of the number of orders per day.

Use case of 2nd SQS Subscriber – Fraud Detection

The other SQS system is a queue to identify the fraudulent transactions that may occur in the e-commerce ecosystem. Think of this like a scenario where you’re concerned with fraud transactions because certain people have ordered something in the past, and the transaction eventually got reversed, and now you want to have a robust, proactive approach that attempts to detect and mitigate fraud.

Similar to the above, here too we may have some fraud detection service hosted on ec2. Again we’re going to poll the queue to figure out when events occur, and once we process the message, we delete that message from the queue so no other threads can receive it.

At the end of the day, this system tries to detect fraudulent transactions. It helps businesses identify the right orders to be delivered against valid transactions. It results in saving a lot of time, money, and effort.

This is where the usage of SNS and SQS shines because events are published and distributed to all the consumers accordingly. The key is that these applications do not have to know about eachother and are completely de-coupled.

Conclusion

SNS and SQS are the bread and butter for developers looking to build distributed microservices requiring asynchronous communication.

If you still feel a bit of ambiguity, then consider these statements

If you want to notify subscribers of an event, use SNS.

If you want to become notified of an event and write custom code to process it, use SQS.

I hope you enjoyed this article. If you have any questions please feel free to reach out via the comments section!