By combining pub/sub and queueing components we are able to build resilient, scalable and fault-tolerant architecture with AWS. This is an overview of SNS (Simple Notification Service), SQS (Simple Queue Service) and how they can be used in isolation or together to send persistent and immediate messages.
SNS is a service where messages in JSON format are pushed to subscribers.
SNS notifications are then formatted for the protocol receiving the message and can be delivered as text messages, emails, and to SQS or HTTP endpoints.
'Topics' are used to allow recipients to subscribe to identical copies of the same message.
SNS can be used to send large numbers of time-sensitive messages to end users in the form of a push notification, SMS and email. Clients can subscribe to topics and specify the endpoint.
In this example from Adnan we see how SNS can be used in conjunction with Lambda to perform calculations. By using SNS we ensure that the message gets through.
SQS is a message queue service that can store messages up to 256KB in any format for up to 12 hours while waiting for a system to pull them to process them.
If the job isn’t processed before the time out expires the message will be placed back in the queue, which could cause the message to be processed twice.
Auto-scaling groups can monitor the SQS group and scale up and down depending on the number of messages in the queue.
The Standard queue uses best effort ordering, FIFO queues guarantee messages are pulled in the order that they arrive.
SQS can be used to throttle workload and process work in batches with non-time sensitive messages being stored for up to 14 days.
In this example from Marcin we see how using Dead Letter Queues allows error handling logic from the application logic
By combining SNS topics and SQS queues together, you can send immediate and persisted messages.
In this example from Frank in his excellent AWS series, we see how to use SNS, SQS and Lambda together.
- The architecture involves S3 event notifications, an SNS topic, an SQS queue, and a Lambda function sending a message to the Slack channel. This shows how it is possible to implement an event processing pipeline with potentially multiple consumers and producers.
This post first appeared on helenanderson.co.nz