Hi Reader 👋🏽
this newsletter is all about Amazon EventBridge, a serverless event bus that makes it easy to build event-driven architectures.
As you may know from our last issue, building event-driven architectures is a powerful way to decouple your services and make them more scalable, resilient, and easier to maintain.
With Amazon EventBridge, you can connect and process data from various sources, such as SaaS applications, AWS services, and custom applications.
In this issue we cover the following topics:
As always, let's start with the infographic about EventBridge:
Amazon EventBridge is one the newer services on AWS. It was launched back in 2019. Originally, it was called CloudWatch Events and was part of the CloudWatch service. It quickly became a whole suite of service itself so AWS branched it out into the service EventBridge.
EventBridge makes it easy to build serverless event-driven architectures on AWS. Its native integrations to different services such as Lambda, SQS, Step Functions, and API Destinations makes it a very useful service.
EventBridge allows you to build event-driven systems in a serverless way. The general goal of an event-driven system is to decouple you consumer & producer from each other.
The main alternative to an event-driven architecture is an API-driven or function-driven architecture.
In this example we have one endpoint create-post.
This endpoint is responsible for publishing a post on a content platform. Once a user hits publish the following actions take place:
All these actions are in the same endpoint function. The coupling between all is very high. There are several gotchas with that.
The Alternative: EDA
Instead of having one endpoint function that directs all different functions that need to be done. The alternative is to publish an event and let the consumer decide what to do.
Instead of letting the create-post endpoint telling the Lambdas what to do:
We publish an event to EventBridge and let the consumers decide what to do:
This makes the overall architecture more decoupled. The API endpoint is only responsible for publishing a post and for nothing else.
Eventbridge helps us with decoupling the architecture into different components. The main components in EventBridge are:
The event bus is the receiver of all events. If you're sending events to EventBridge it is mandatory to define the event bus name.
EventBridge distinguishes between different types of event buses:
Event rules are a very powerful feature in EventBridge. They define which events will be routed to which targets. This can be done on the whole message body.
Let's say we have the following event:
We only want to route this event in case the value of audioIsEnabled is set to true. The rule for that can look like that:
Targets are the consumers of the event rule. EventBridge has powerful integrations with many AWS services such as
These are the three main components you need to understand if you want to work with EventBridge.
Now, that we understand the basics lets an example use case.
One use case is the integration of third-party vendors into AWS. Having all workloads in AWS makes many things easier. Observability, Infrastructure as code, and monitoring are a few of these things.
But there are many third-party providers that have very good products but are outside of AWS. For example, MongoDB, Auth0, or Zendesk. EventBridge allows you to integrate them easily.
MongoDB for example has native integration with EventBridge. EventBridge can listen to triggers like data inserted, updated, or removed. This event will be present in EventBridge and can be handled like every other event.
In this example, we can listen to published posts on MongoDB. Once a post was published we can do certain actions like creating an audio version or sending out newsletters.
EventBridge offers even more capabilities. Features like Archive & Replay, Schema Discovery, and Error Handling are also very important for EventBridge. We wrote a whole chapter about that. With this newsletter you get this chapter for free! EventBridge - Sample Chapter
Thank you for reading this issue. If you have a specific service, architecture, or problem in mind we should tackle in one of the next newsletters please let us know! Simply reply to this email 😊
Sandro & Tobi ✌🏽
Join our community of over 8,800 readers delving into AWS. We highlight real-world best practices through easy-to-understand visualizations and one-pagers. Expect a fresh newsletter edition every two weeks.
⌛ Reading time: 10 minutes 🎓 Main Learning: Building a Serverless Platform With SST, Lambda & Next.js ✍️ Read the Full Post Online 🔗 Hey Reader 👋🏽 In this post, we want to guide you through our complete setup for our custom video platform. Our CloudWatch Book's Video Section This starts from the purchase to actually accessing our custom build video-access platform. Overview about our CloudWatch Book Landing Page & Video Platform Architecture We'll explain why we decided against a third-party...
⌛ Reading time: 11 minutes 🎓 Main Learning: Step Functions - Express vs. Standard 👾 GitHub Code ✍️ Blog Post Hey Reader while Sandro is learning something new at the AWS Community Day in Munich today, we'll explore Express and Standard Step Functions, the two types of workflows offered by AWS Step Functions. We’ll break down their differences, when to use each, and the benefits of both. Example Application: running both workflow types to see their performance differences If you want to try...
Hey Reader First things first: we apologize for not providing updates on The CloudWatch Book for a while! 😢 Sometimes, things don't go as planned and unexpected obstacles arise. But now, we're back in action, creating videos and putting the final touches on the book's content! 🎥 Don't just take our word for it! As an early subscriber, here's a free video from one of our favorite chapters: Anomaly Detection 🐛 In this deep-dive, you'll learn how to detect unusual patterns in metrics without...