The most common architectures to build distributed applications are: choreographed, also known as event-driven and orchestrated architectures. In this article, I want to show you how to design and build event-driven applications in AWS. For that, we will use Amazon EventBridge.
First, we are going to look at what is Amazon EventBridge. Then we will jump into the design of event-driven applications. And finally, I will show you a lot of features and best practices from Amazon EventBridge to make your development easier.
Introduction to Amazon EventBridge
Amazon EventBridge is a serverless event bus that makes it easier to build event-driven applications at scale using events generated from your applications, integrated Software-as-a-Service (SaaS) applications, and AWS services.
EventBridge works with rules. You define rules in the bus and when an event comes into de bus, EventBridge will compare that event against all the rules. If a rule matches, then EventBridge sends the event to the target. In this way you can have a decoupled architecture, as the producer of the event doesn't need to know about the consumer. The producer just creates an event and sends it to the event bus.
In the following video, we look at Amazon EventBridge and how to build a simple application using AWS SAM.
How to design event-driven applications
You can use EventBridge to build an event-driven application, but how you design one? Designing an event-driven application so everything gets documented and you can easily extend it takes some practice. In this video, you will learn how to design step-by-step an event-driven architecture.
More features of EventBridge to help you build your application
EventBridge has lots of really interesting features and you can do quite a lot of things by leveraging them. In this section, I want to show you some of the most useful ones to help you build your applications.
Custom buses and central logging of events
Finding what is going on in an event-driven application can be hard. If you want to know if there is an issue, knowing what triggers what is quite challenging, even if you have a good documentation of your events. You might need to visit many consoles or logs to figure out where it went wrong. With a central place where all your events are located, you can start your investigation there. You can see what was the last event emitted and start your search in that service and see where it went wrong.
In this video, you will learn how to leverage custom buses to get a central logging for all the events in your application, so you can debug and pinpoint problems in your application super easily!
EventBridge API Destinations is a feature that allows you easily to call third party APIs directly from an EventBridge rule. This allows you to remove extra code and complexity in your applications.
Dead Letter Queues
Sometimes EventBridge cannot successfully deliver a event to the target specified in a rule. This can happen when, for example, the target resource is unavailable, when EventBridge lacks permission to the target resource, or due to network conditions.
EventBridge has a retry policy and will keep on trying to send your event, but after all the retry attempts are exhausted, EventBridge drops the event. To avoid losing events after they failed to be delivered, you can configure a dead-letter queue (DLQ) and send the failed events to it for processing later.
In this video, you will learn how to configure a DLQ into an EventBridge rule and how to set a CloudWatch alarm when this happens.
But you like to see the demos with AWS CDK...
In these videos, you will learn how to do what we did before with AWS EventBridge but with AWS CDK.
Amazon EventBridge is the way to go when you need to build an event-driven application. This service has so many functionalities, so before getting to code I recommend you learn the basics about the service, its integrations and how to create rules.
You can check a similar post about Building orchestrated applications with AWS Step Functions