The Simple Notification Service, also called SNS implements, a one-to-many message distribution model. A single message is published to a topic and that message gets published to one or more subscribers to the topic. In this case, the interaction point that is similar to a mailbox is called a topic. Applications generating messages are called publishers, and systems receiving messages are called subscribers. A topic does not store messages like queues do; there is no message preservation in a topic. Once a message is published to a topic, the message is pushed to all existing subscribers. Once a message is published, there is no mechanism to recall the message back. SNS can send push notification messages to mobile devices and desktops using one of the many supported push notification services, including the Apple push notification service for both iOS and macOS 10, the Windows push notification service, the Amazon device messaging, the Baidu cloud push mechanism, and the Firebase cloud messaging.

Subscriber types can also be HTTPS URL endpoints, email addresses, AWS lambda functions, or even text messages to phone numbers via short message service for clients in over 200 countries and for an expanded set of use cases like multi-factor authentication and one time passwords. You can also mark SMS messages as transactional or promotional based on the content of your messages. The AWS documentation for Amazon SNS is updated regularly to reflect the details of using SMS depending on the destination country, checked for details before using SNS for sending text messages. Amazon SNS can also publish messages to SQS queues to implement reliable and asynchronous, fan out message distribution patterns. The idea of notifications is to maximize the message distribution by permitting the same message to be pushed to multiple subscribers to the same topic. SNS is the go-to service in order to implement notifications using AWS services including events. You can seamlessly scale from a handful of messages per day to millions of messages or more. A single topic can handle over 12 million subscriptions, and you can have up to 100,000 topics if needed and publishing at a rate of 30,000 messages per second in the US east1 region.

The message processing rate per second changes between regions, so please verify the documentation for details in the region you intend to use. The maximum message size is 256 kilobytes, and SNS breaks messages into 64 kilobyte chunks and deals with them as individual requests. Similar to SQS, Amazon SNS producers can use the SNS Extended Client Library for Java in order to publish messages that are larger than 256 kilobytes and up to 2 gigabytes in size. The library uses Amazon S3 to store the message payload and publishes the reference to the object to the topic. Subscribers from SQS can use the SQS Extended Client Library for Java to retrieve the payloads from S3, lambda functions, and other endpoints will need to use the Payload Offloading Java Common Library for AWS, and this is in order to access the object stored in S3. Message filtering enables topic subscribers to selectively receive only a subset of the messages that interest them. As opposed to receiving all the messages published to a topic, this is done using a subscription filter policy in JSON format.

The JSON policy contains attributes that define which messages to deliver to the subscriber. SNS compares the attributes on each message, and when the message is published, that comparison happens to the attributes in the filter for each subscriber. The topic will send the message only if any of the attributes in the message match the subscriber's filter policy attributes. This filtering mechanism decouples any message routing logic from the message publishers and eliminates the need to use different topics for different conditions. It allows you to use a single topic for publishers and differentiate your messages using attributes that each corresponding subscriber will match in its filter policy. An Amazon SNS Delivery Policy can be used to control the retry pattern for message delivery as linear, geometric, exponential backoff, maximum and minimum retry delays, and other parameters during message delivery by the SNS topic.

When the message delivery retry policy is exhausted, Amazon SNS can move the message to a dead-letter queue. A dead-letter queue, as discussed before, is an Amazon SQS queue that an Amazon SNS subscription can target for messages that can't be delivered to subscribers successfully. Messages that can't be delivered due to client errors or server errors are held in the dead-letter queue for further analysis or reprocessing. So, let's compare these two messaging services side by side. Amazon SNS allows applications to send time-critical messages to multiple subscribers through a push mechanism; Amazon SQS exchanges messages through a polling model, sending and receiving components are decoupled. Amazon SQS provides flexibility for distributed components of applications to send and receive messages without requiring each component to be concurrently available. This is due to the message persistency feature and the decoupling mechanism. In order to find out identical messages to multiple SQS queues, the process is, number one, create a topic first using SNS, then create and subscribe multiple SQS queues to the SNS topic.

With that defined, whenever a message is sent to the SNS topic, the message will be fanned out to the SQS queues. SNS will deliver the message to all the SQS queues that are subscribed to the topic. And once the message is put on each queue, this can trigger any polling application as needed. The process in diagram form will look as shown in your screen. This is your basic fan-out implementation using SNS and SQS combined. In this basic fragment, all three queues are subscribed to the topic for notifications and the same message will be published to all three in order to dispatch the image processing required. We can expand on this scenario and include the fan-out portion into an existing application for image processing. The user uploads the image and then manually triggers a function that sends the necessary message to a designated SNS topic. This will start the rest of the workflow.

We can improve on the prior diagram because Amazon S3 buckets are event-aware and they can trigger a notification to SNS when an object is uploaded. In this evolved scenario, uploading the image to Amazon S3 triggers an event notification which sends the message to the SNS topic automatically. Our diagram then evolves as shown on your screen. Please note the significant differences between this last application diagram and the diagram that we used to start this decoupling conversation. They are significantly different with this last one being more resilient and agile.