Hi Reader 👋🏽

in this issue we'll explore the core services to build Event-Driven Architectures (EDA) with AWS. 📨

Like the name already suggest, EDA do rely on events (=> messages) that are used to trigger code executions.

An event can be any change or update in any part of the system, e.g. a user interaction or a message from another system.

By building apps in this way, we can deliver exceptional high responsiveness, flexibility, and scalability.

Who is our major suspect for creating such architectures on AWS? 🕵️‍♀️
=> Actually, there are 3 of them! ✨

• Simple Queue Service (SQS)
• Simple Notification Service (SNS)
• EventBridge

But how do they differ and when to use what?

That's exactly what we want to explore in this weeks issue!

• Fundamentals of Messaging Systems
• Benefits of Messaging Systems
• Introduction to & Main Concepts of SQS, SNS, and EventBridge
• Comparison & When to Use What

Let's go! 🚀

​

Fundamentals of Messaging

Services like SNS, SQS, and EventBridge provide a way to send and receive messages between different components of an application. This allows them to communicate and therefore work together.

This can be useful in situations where components need to be decoupled, such as for...

• handling tasks that may take a long time to finish or
• sending notifications to different parts of the application

Additionally, they help to make systems very resilient as they allow them to respond to incidents with reprocessing of events.

Benefits of Messaging Systems

Those services and the resulting architecture when using them properly result in various benefits, including:

• Scalability: messaging systems can quickly adopt to changing traffic volumes, which makes them ideal for application with rapidly varying workloads.
• Resilience & Decoupling: with messaging systems, components can be strictly decoupled, which can lead to higher resiliency as individual components can fail without affecting the whole systems. This reduces
• Asynchronous Communication: messaging systems allow you to invoke components asynchronously, which allow for a more efficient use of resources and often also improved performance.
• Reliability: Due to message retention periods and the option for automated reprocessing of events in the case of failure, messages are delivered with high reliability. Messaging systems allow you to build application ecosystems that do not have a single point of complete failure.
• Cost-Effectiveness: messaging systems can be highly cost efficient, as they only use resources when messages are processed. You don't need to pay for idling resources.

Those benefits are just an outtake and surely nothing comes with trade-offs compared to monolithic and/or synchronous systems.

Simple Queue Service (SQS)

SQS, a fully-managed queuing service, allows you to send, store, and receive messages between various AWS services and components. It enables asynchronous communication between different parts of your application.

The main concepts of SQS are:

• Queues: queues are the storage the payload (=messages) you want to transfer between different components. They come in different variations: First-In-First-Out (FIFO - messages are processed in the order in they are received), Standard (higher throughput, but no guarantees for the processing order).
• Polling: SQS doesn't push messages to other service like Lambda. They need to get polled. SQS supports different modes of polling: Short Polling (if there are no available messages, SQS will immediately sent an empty response) and Long Polling (if there's no currently available message, SQS will wait for a configured wait time or until a message is available before sending a response).

Simple Notification Service (SNS)

SNS is a managed messaging service that allows you to (mass) send notifications to either endpoints or clients. It's based on the publish/subscribed pattern and can be therefore used to fan-out messages to multiple recipients.

Key concepts of SNS are:

• Publish/Subscribe: SNS follows the publish/subscribe messaging paradigm, meaning that messages are actively pushed to clients, eliminating the need to poll.
• Topics: a topic is a dedicated collection of messages. A client can subscribe to such a topic and every time a message is published, all of the subscribed clients are notified.

EventBridge

EventBridge is a serverless event bus service that allows you to easily route events between different services and components. It drastically helps to build loosely-coupled systems that can quickly adapt to changing requirements.

Key concepts:

• Events: an event is a JSON message that always includes the properties detail (the actual message payload), the detail-type (a description of the event type), and the source (the originating source of the event).
• Event Bus: the event bus is the receiver of all events. There are different types of event buses: Default Bus (the default bus for AWS internal events, e.g. the launch of an EC2 instance), Custom Bus (for your custom events), and Partner Event Bus (for partner events, e.g. by MongoDB, Auth0, or Zendesk).
• Schemas: a schema is a description of your event properties. It defines the structure of your event. Publishing those schemas help consumer to integrate as the know which events they can expect to receive.
• Sources & Targets: sources describe where events are coming from, while targets are the consumers of your events.
• Rules: rules define how to route events to its consumers. Once an event arrives the rule sends it to the consumer if the event pattern matches.

​

Comparison - When to Use What

We've covered the fundamentals of the three core messaging services. As they not only differ in their feature set but also in how they work, it's important to know when to use which service.

Let's phrase this into a small summary:

1. Use SQS to decoupled components that need a reliable 1:1 asynchronous communication. This is especially valid if you need in which order messages are worked through. SQS is also the right choice to add fault-tolerance between native-service connections like S3 notifications to Lambda.
2. Use SNS if you want to actively push messages to a large number of consumers. Due to it's great fan-out capabilities and the push-based instead of poll-based approach, it's also the right choice for interactive / real-time applications.
3. Use EventBridge if you want to publish messages to different consumers with different requirements and if you want to strictly decouple the sender and receivers. It's great for connecting components of different teams to incorporate them into the same eco-system.

​

Conclusion

By leveraging SQS, SNS, and EventBridge, you can build highly fault-tolerant, event-driven systems with a high degree of flexibility as components are never strictly coupled.

Due to their pay-as-you-go pricing models, they are also a perfect starting point to discover, learn about and build complex architectures on AWS.

We hope you've learned something new in this issue!

See you in two weeks!

Sandro & Tobi 👋

---

If you want to continue reading, have a look at our recent blog posts in which we cover the different AWS Compute Services or How to Keep Your Account Secure with Multi-Factor Authentication 📚