An Overview of SNS and SQS

No matter what level you are as a software engineer, AWS can always be an intimidating place. Recently, in my current role as a software engineer I had to leverage two tools which I had no idea how to use. Those being the Simple Notification Service (SNS) and the Simple Queue Service (SQS). In this article I am going to go over what they are.

Simple Notification Service (SNS)

Both SNS and SQS are messaging services however they have different use cases. SNS is a publish-subscribe messaging service which allows you to send messages to a topic which can have multiple subscribers receiving those messages.

A topic is an access point for allowing recipients to subscribe for identical copies of the same notification. When you publish a message to a topic, all of the subscribers to that topic receive a copy of that message. It’s a bit like subscribing to a YouTuber, where you will be notified every time the account uploads a video

SNS is often used to send notifications to email or SMS subscribers, or to trigger workflows in other AWS services.

Imagine you have a streaming service such as Netlfix and you want to notify you users about a new TV-series that is available. To do this, you can set up SNS to send an email to a user for every new release on your platform. Here’s how it would work:

1. Your streaming service sends a message to an SNS topic when a new release comes out.
2. SNS sends the message to all email subscribers of the topic.
3. Each subscriber receives an email notification with the detail of the new release.

Simple Queue Service (SQS)

SQS on the other hand is a message queue service that enables you to send, store and receive messages between software components at any volume, without losing messages or requiring other services to be available. Essentially it eliminates the overhead associated with managing and operating message oriented middleware and empowers developers to focus on differentiating work.

Let’s have a look at what a high level example of SQS would look like:

1. A producer sends a message to an SQS queue.
2. The message is stored in the queue until a consumer retrieves it. Where a consumer and producer can be any type of application or service that needs to communicate with other components asynchronously. A producer is one that sends messages whereas a consumer is one that receives messages.
3. A consumer retrieves the message from the queue and processes it.
4. Once the consumer has finished processing the message, it sends a request to delete the message from the queue. Essentially SNS is used to broadcast messages towards one or more recipients whereas SQS is used for message queuing and sending messages to a single recipient (i.e. a software component or service).

How they work together

We can however go one step further, where we can combine the powers of both SNS and SQS.

1. A producer sends a message to an SQS queue.
2. The message is stored in the queue until a consumer retrieves it
3. While the message is being processed, the consumer can send progress updates to an SNS topic
4. Subscribers to the SNS topic can receive the progress in real-time through various means.
5. When the message has been fully processed, the consumer can send a final notification to the SNS topic indicating that the task is complete.

What are the benefits?

This all sounds well and good, but why would you want to use SNS and SQS?

Decoupling: SQS can be used to decouple the components of a distributed system, allowing them to operate independently and asynchronously. This can improve the scalability and reliability of the system.

Asynchrony: SNS can be used to send notifications asynchronously to subscribed users or systems, such as those in event-driven systems.

Flexibility: SQS and SNS can be used together to build a variety of distributed systems ranging from simple message passing to complex event-driven architectures.