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:

1. Introduction 🎓
2. Decoupling Consumer & Producer 🎆
3. Basic Components - Bus, Rules, Targets 🧱
4. Example Use Case 🏗️
5. Bonus: Get a free chapter on EventBridge of our book - AWS For the Real World

Infographic

As always, let's start with the infographic about EventBridge:

---

Introduction 🎓

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.

Decoupling Consumer & Producer 🎆

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:

1. Publish the post
2. Save Analytics
3. Backup the post
4. Send a newsletter

All these actions are in the same endpoint function. The coupling between all is very high. There are several gotchas with that.

• Adding or removing actions requires to touch the whole endpoint
• Error handling gets very complicated. How and what should be retried?
• One change can break the whole endpoint
• The endpoint is responsible for several actions and hurts the Single Responsibility Principle

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.

Basic Components - Bus, Rules, Targets 🧱

Eventbridge helps us with decoupling the architecture into different components. The main components in EventBridge are:

• Event Bus - Where to publish the events on
• Event Rules - How to route the events
• Event Targets - What is the consumer of the event

The Event Bus Receives all Events

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:

• Default Bus - Each AWS account has one and all internal events will be sent to this bus. For example, state changes in your ECS tasks.
• Custom Bus - You need to send custom events to a custom bus
• Partner Event Bus - EventBridge allows integration with third-party verndors such as Auth0, MongoDB, or Zendesk. These events will be sent to a partner event bus

​

Event Rules Define How to Route Events

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:

EventBridge Can Use a Variety of AWS Services as Targets

Targets are the consumers of the event rule. EventBridge has powerful integrations with many AWS services such as

• API Gateway
• SQS
• SNS
• CloudWatch
• Lambda

These are the three main components you need to understand if you want to work with EventBridge.

Example Use Case 🏗️

Now, that we understand the basics lets an example use case.

Integrating Third-Party Vendors - Integrate MongoDB

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.

​

Bonus: EventBridge Chapter

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​

​

Thanks ✌🏽

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 ✌🏽

​

​

​