When developing an application, many tasks related to storage, processing, and execution happen with efficient messaging services at every application layer. Messaging services work in a proper standard to ensure uninterrupted deliverance of events or tasks. Amazon SQS and SNS are the two messaging standards that ensure the smooth execution of events.
Amazon Simple Notification Service known as Amazon SNS is a distributed publish-subscribe system. Messages are pushed to subscribers as and when they are sent by publishers to SNS.
Amazon Simple Queue Service (SQS) also known as Amazon SQS is a distributed queuing system. Messages are NOT pushed to receivers. Receivers have to poll or pull messages from SQS.
Amazon SNS
Amazon Simple Notification Service (Amazon SNS) is an easy, fast, and flexible that lets you send individual or bulk messages to large numbers of receivers from the cloud.
It offers developers a highly scalable, flexible, and cost-effective capability to publish messages from an application and immediately deliver them to subscribers or other applications. Amazon SNS follows the “publish-subscribe” (pub-sub) messaging paradigm, with notifications being delivered to clients using a “push” mechanism that eliminates the need to periodically check or “poll” for new information and updates.
Amazon SNS offers several benefits such as:
- Instantaneous, push-based delivery (no polling)
- Simple APIs and easy integration with applications
- Flexible message delivery over multiple transport protocols
- Inexpensive, pay-as-you-go model with no up-front costs
- Web-based AWS Management Console offers the simplicity of a point-and-click interface
Some example uses for Amazon SNS notifications are:
- In workflow systems to relay events among distributed computer applications
- Move data between data stores or update records in business systems
- Updates and notifications for validation, approval, inventory changes and shipment status
Amazon SQS
Amazon SQS is a distributed queuing system. Messages are not pushed to receivers. Messages can’t be received by multiple receivers at the same time. Anyone receiver can receive a message, process and delete it. Other receivers do not receive the same message later. Polling inherently introduces some latency in message delivery in SQS, unlike SNS where messages are immediately pushed to subscribers.
SQS offers two types of message queues. Standard queues offer maximum throughput, best-effort ordering, and at-least-once delivery. SQS FIFO queues are designed to guarantee that messages are processed exactly once, in the exact order that they are sent.
Amazon SQS offers several benefits:
- Eliminate administrative overhead
- Reliably deliver message
- Keep sensitive data secure
- Scale elastically and cost-effectively
SQS is primarily used to decouple applications or integrate applications. Messages are stored in SQS for a shorter time (maximum 14 days). While SNS distributes several copies of messages to multiple subscribers. If you want to replicate data generated by an application to several storage systems, you could use SNS and send this data to multiple subscribers, each replicating the messages it receives to different storage systems.
Difference between AWS SNS & AWS SQS
- Reliability of Messages
A large volume of data can be sent with the help of Amazon SQS. Messages in the SQS are sent with the advantage of having an application decoupling component. Because of the application decoupling component, only a particular application component is effected in case of any failure rather than disturbing the whole process.
Thus, this ensures that neither of the message sending process is effected on the cost of failure generated in any other application component. Moreover, multiple message copies are stored to be made available for use whenever the need arises. Here, in Amazon SNS, unlike its counterpart Amazon SQS, the messages are dependent on the availability of SNS Topics. Topics in SNS act as communication channel access point.
For the effective deliverance of messages, the data related to it is stored at multiple geographical storages. Application decoupling is not done here as in Amazon SQS, but in case of any error from subscriber endpoints initiatives like message retry policies and dead-letter queues are initiated for effective deliverance of messages. - Scalability
For a better service to the users in terms of their growing usage, Amazon SQS depends on the wider network of AWS Cloud. If the applications are experiencing increasing workload, Amazon SQS scales accordingly with the application workload to provide uninterrupted services.
An unlimited amount of messages per queue can be sent with the help of the standard queues in the SQS. Amazon SNS is also dependent on the wider network of AWS for effective message deliverance. However, the difference in terms of scalability lies in the working module of both.
Amazon SQS works on messaging functions of software components only, whereas SNS is not only focussed on system communications but can be used for direct user communication also. Millions of messages per second can be sent even in short interval traffic patterns, thus enabling the uninterrupted services. - Entity Type
SQS: Queue (Similar to JMS)
SNS: Topic (Pub/Sub) - Message consumption
SQS: Pull Mechanism — Consumers poll and pull messages from SQS
SNS: Push Mechanism — SNS Pushes messages to consumers - Use Case
SQS: Decoupling two applications and allowing parallel asynchronous processing.
SNS: Fanout — Meaning allowing the same message to be processed in multiple ways. - Persistence
SQS: Messages are persisted for some (configurable) duration is no consumer-available.
SNS: No persistence. Whichever consumer is present at the time of message arrival, get the message and the message is deleted. If no consumers are available then the message is lost.
In SQS the message delivery is guaranteed but in SNS it is not. - Consumer Type
SQS: All the consumers are supposed to be identical and hence process the messages in exactly the same way.
SNS: All the consumers are (supposed to be) processing the messages in different ways.
Sample applications
SQS: Jobs framework. Where the Jobs are submitted to SQS and the consumers at the other end can process the jobs asynchronously. And if the job frequency increases then the number of consumers can be increased for parallel processing.
SNS: Image processing. If someone uploads an image to S3 then watermark that image, create a thumbnail and also send a ThankYou email. In that case, S3 can send a notification to SNS Topic and 3 consumers can be attached to SNS topic. 1st one watermarks the image, 2nd one creates a thumbnail and the 3rd one send a ThankYou email. All of them receiving the same message (image URL) and doing their corresponding processing in parallel.
Use cases for AWS SNS & AWS SQS
Even though there’s some overlap in their use cases, both SQS and SNS have their own spotlight:
Use SNS if:
- multiple subscribers is a requirement
- sending SMS/E-mail out of the box is handy
Use SQS if:
- only one subscriber is needed
- batching is important
SNS and SQS can be used together for multiple reasons:
- There may be different kinds of subscribers where some need the immediate delivery of messages, where some would require the message to persist, for later usage via polling. See this link.
- The “Fanout Pattern.” This is for the asynchronous processing of messages. When a message is published to SNS, it can distribute it to multiple SQS queues in parallel. This can be great when loading thumbnails in an application in parallel when images are being published. See this link.
- Persistent storage. When a service that is going to process a message is not reliable. In a case like this, if SNS pushes a notification to a Service, and that service is unavailable, then the notification will be lost. Therefore we can use SQS as persistent storage and then process it afterwards.
