DEV Community

Cover image for About Amazon SNS & Pub/Sub Architecture
awedis for AWS Community Builders

Posted on

About Amazon SNS & Pub/Sub Architecture

In this article will delve into one of the messaging techniques used in event-driven architectures, which is Pub/Sub.

About Amazon SNS - Push Notification Service:

AWS SNS (Simple Notification Service) is a messaging and mobile push notification service provided by Amazon Web Services (AWS). It allows developers to send messages or notifications to a large number of recipients, such as end-users or other applications, via multiple communication protocols like SMS, email, mobile push notifications, and others. It's commonly used to build distributed, event-driven applications and microservices.

About Pub/Sub:

Publish/Subscribe messaging, or pub/sub messaging, is a form of asynchronous service-to-service communication used in serverless and microservices architectures. In a pub/sub model, any message published to a topic is immediately received by all of the subscribers to the topic.

The intermediate system that functions as an event router is referred to as a "Topic". Any service that has subscribed to this Topic will receive messages whenever they are published by the designated publisher.

Examples:

Let's see a simple example of using the Serverless Framework to implement a Pub/Sub architecture using AWS SNS and AWS Lambda. The publish function publishes a message to the test-topic SNS topic, and the process function subscribes to the topic and processes incoming messages.

  • The SNS topic definition to your serverless.yml file:
resources:
  MySNSTopic:
    Type: AWS::SNS::Topic
    Properties:
      TopicName: test-topic
Enter fullscreen mode Exit fullscreen mode
  • Our two Lambda functions, the one that will publish a message to the SNS topic (publisher), and the will consumer the message (subscriber)
const AWS = require('aws-sdk');
const sns = new AWS.SNS();

module.exports.publisher = async (event) => {
  const params = {
    Message: event.body,
    TopicArn: process.env.SNS_TOPIC
  };
  const result = await sns.publish(params).promise();
  console.log('result =>', result);

  return {
    statusCode: 200,
    body: 'Message published successfully'
  }
}

module.exports.subscriber = async (event) => {
  const message = event.Records[0].Sns.Message;
  console.log(`Received message: ${message}`);

  return {
    statusCode: 200,
    body: 'Message processed successfully'
  }
}
Enter fullscreen mode Exit fullscreen mode
  • The publisher function will be a simple API, which we will trigger later on from postman. And the subscriber (If an arn: is specified, the framework will give permission to the topic to invoke the function and subscribe the function to the topic)
publisher:
  handler: src/modules/PubSub/controller/lambda.publisher
  events:
    - http:
        method: post
        path: sns/pub
        cors: true
subscriber:
  handler: src/modules/PubSub/controller/lambda.subscriber
  events:
    - sns:
        arn: arn:aws:sns:${env:region}:${env:accountId}:test-topic
Enter fullscreen mode Exit fullscreen mode

That's it now let's try to hit our API, will pass the following body:

{
  "data": "test"
}
Enter fullscreen mode Exit fullscreen mode

Now you can see our subscriber function being triggered and will print the following body message inside the cloudwatch

Conclusion:

In event-driven architecture it's always good practice to spread your services, and make them decoupled, this will make your infrastructure much easier to be managed and scaled at the same time. πŸ™‚

This was a short one, but I hope it will help someone out there to tackle a problem or have an "aha" moment.

This article is part of the "Messaging with Serverless" series that I have been writing for a while. If you are interested in reading about other serverless offerings from AWS, feel free to visit the links below.

Top comments (0)