Messaging in AWS Using SNS and SQS

There are two main communication paradigms in event-driven architectures used in microservices design. 

  • Queueing provides a messaging system to integrate two different services.
  • Publish/subscribe messaging is a form of asynchronous service-to-service communication used in microservices architectures. In contrast to queueing, publish/subscribe messaging allows multiple consumers to receive each message in a topic. 

They allow us to de-couple producers and consumers of messages. By combining publish/subscribe messaging systems with queueing systems, we can build fault-tolerant, scalable, resilient, and reactive application architectures. Amazon Web Services (AWS) offers a number of services which provide these two communication paradigms. In this article, we will learn how to program AWS services – Simple Notification Service (SNS) for publish/subscribe messaging and Simple Queue Service (SQS) for queueing using AWS SDK in Java.

Amazon SQS as an Event Source to AWS Lambda : A Deep Dive

SQS as an event source to Lambda is a game changer. I can now send all my event-based messages, logs, and analytics from my iOS application directly to an SQS queue. Sending these messages to SQS hasn’t changed; SQS is still low latency and batch capable, has very high throughput, and is an affordable alternative to using other storage options and no data store schema or tables to setup. What has changed is the managed backend resources for consuming content sent to the queue. All the “consuming of an SQS queue” is managed for you and we’ll explore what role each service is playing as part of this new architecture.

In this article, I’ll go over the details of SQS as an event source, the Lambda integration, and then we’ll quickly build this architecture using pre-built AWS CloudFormation templates to provision the backend resources. After you are up and running, follow along for a deeper dive into this serverless event-driven architecture.