SNS, SQS, and EventBridge
In this guide, we will be looking at when to use SNS, SQS, and EventBridge
AGENDA
- What is SQS, SNS and EventBridge
- When To Use What RESOURCE
SNS stands for simple notification service and SQS stands for simple queue service.
SNS
- It uses a publisher/subscriber system. You may own a topic, publish to that topic and subscribers get notified of events that are delivered to that topic.
Topics are the first-class citizens of SNS. They are similar to Queues except that topics aren’t holding polls for messaging. They’re essentially created to have a particular theme like orders topic, transactions topic, logging topic. Anytime an event occurs in an application, the application that owns that data will publish a message to the topic and that topic will deliver an identical copy of that message to all the different subscribers of that topic.
So if we have an orders topic and many services are interested in receiving updates on orders, we will subscribe all our services to that topic so they can be notified whenever an event occurs and process that event at their own pace.
Messages do have size limits,
- Publishing a message on a topic can deliver to many subscribers (fan-out) of different types (SQS, Lambda, Email)
- Do other systems care about events? If your answer is yes, then you should use SNS because you want to publish a message to your topic and potentially tell other people that a particular event happened.
SQS
- It’s a queueing service for message processing. An SQS could be a subscriber to an SNS. Whenever someone publishes a message to an SNS your SQS queue gets a message in it that can be processed at a later time.
- SQS allows application owners to publish messages to a queue and in doing so decouple their applications from one another.
Queues are the first-class citizens of SQS. It’s what you’re going to create through the console, CLI, or Infrastructure as code. Queues are the destination where you, as an application owner, are going to be publishing messages. It’s a temporary holding pool where you can publish a message to.
Polling is the mechanism by which a subscriber or a person that wants to receive the messages will process them so applications that want to retrieve messages from the queue will poll that queue so that they can process them successfully.
- A system that must poll the Queue to discover new events.
- Messages in the queue are typically processed by a single consumer or a single service with a very narrow responsibility. If they both care about the same events they can have their own separate queues.
- Does your system care about an event? Do you care when something happened, so you’re the receiver of this data and if it’s true SQS is the right choice for you.
EventBridge
EventBridge is similar to SNS has some improvements on SNS and does things a little differently. The main concepts of EventBrdige are:
- Message Bus
- Events
- Rules
- Targets
Message Bus is the same as a topic, where you publish a message to the event bus and you have a different recipient of those messages.
Events can be constructed by an application such as order service, etc. It can also be emitted by AWS service itself like EC2. Whenever an instance gets spun up you can integrate EC2 with your event bus so that events automatically get generated whenever they occur.
You can also integrate it with other third-party saas or software as a service provider like Datadog, PagerDuty, and Shopify. Instead of writing your own custom function code, they will provide the functionality for you because of the seamless integrations.
Rules match incoming events and send them to their corresponding targets for processing.
Targets are your destination endpoints. They are what is going to be invoked at the end of the day.
They have other interesting features like message filtering (which allows you to filter messages)
Gracias
Enjoyed the read? Leave some ‘claps’ below so others can find this post. 🙂
Check out my other posts :)
