This is part 3 of our series: How we build EDA at Hashnode on AWS.

In part 2 we decided to use Amazon EventBridge as our main service to build the Event-Driven Architecture (EDA). Part 3 covers the basic functionality of EventBridge.

What is EventBridge

Amazon EventBridge is a service to build serverless event-driven architectures. It was launched in 2019. Formerly it was part of the CloudWatch Service and was called CloudWatch Events.

EventBridge allows you to build EDA and integrate it with many AWS services. Each AWS Account has a default event bus. This event bus receives all events from internal AWS Services like ECS, EC2, or Lambda.

Additionally, EventBridge partners with many third-party SaaS tools such as MongoDB, Zendesk, or Shopify. This makes the integration even easier.

Components

Amazon EventBridge has several components. Let's go through the components one by one and see what their functionality is.

Event Bus

One of the main components of EventBridge is an event bus. You send all events from your event producer to an event bus.

Each AWS account has a default event bus. This default event bus receives events from within AWS.

Examples of these events are:

• EC2 instance was created

• ECS task state changed

• EventBridge schema changed

You can also create a custom event bus. You can send any kind of event you want to the custom event bus.

Partner events (Auth0, MongoDB, etc.) are creating their own custom event bus.

Rule

The second component is the event rule.

EventBridge allows you to create rules. A rule belongs to an event bus. The rule defines in which cases the event will be sent to the consumers.

The rule has an event pattern. This is one of the core functionalities and strengths of EventBridge. The rule matches the whole message body.

An incoming event is a JSON object. You can match any key-value pair in this JSON object.

If a rule matches the event will be forwarded to a target.

Here are some examples of things you can match:

• Value is null: "data":[null]

• Value is empty: "data":[""]

• Value equals something "name": ["Sandro"]

There are many more operators available.

For our example above, the rule is the following:

{
  "detail-type": ["postPublished"],
  "source": ["hashnode.api"],
  "detail": {
    "data": {
      "publication": {
        "audioBlogEnabled": [ true ]
      }
    }
  }
}

Only events that look like that will be matched by the rule:

{
    "detail-type": "postPublished",
    "source": "hashnode.api",
    "detail": {
        "data": {
            "publication": {
                "audioBlogEnabled": true
            }
        }
    }
}

If audioBlogEnabled is false or missing the rule won't match and therefore, no target will be called.

What happens if a rule matches? The event will be pushed to its targets.

Target

A target is the subscriber of an event rule. There are many target types available in EventBridge. Some of the most important ones are:

• Lambda

• SNS Topic

• SQS Queue

• Step Functions

• API Destinations

You can see a list of all supported targets here.

Once the rule matches the target will be invoked and the rule will be sent to this target.

Cron Jobs

Cron jobs are regularly executed scripts. EventBridge allows you to run jobs at regular intervals. A cron job can either be defined by a schedule like run every minute or by the cron syntax, for example, 0 10 * * ? *.

EventBridge calls the target in this interval. Cron jobs live on the default event bus.

Archive & Replay

A really nice feature that was already mentioned in the last post is Archive & Replay.

If you enable the archive functionality, EventBridge will create an archive of all events that are sent to this event bus. This comes in super handy when you introduced a bug and want to run all events again.

Also, this is pretty useful for using production workloads in a development environment.

With the replay functionality, you can define a start and end time from when the events should be replayed and on which event bus.

Schema Bindings

EventBridge allows you to activate a schema discovery. The schema discovery can then go ahead and create type bindings automatically for you. For example, you can activate schema discovery for your event bus. Then send events to this bus and finally, generate TypeScript types.

While this idea is really nice it has some drawbacks so we cannot use it right now at Hashnode. For example, it is not really possible to use optional fields.

This is why I won't dive deeper into this topic.

Target Lambda

There are many ways to execute your business logic in a target attached to an EventBridge rule. We chose Lambda as the main target for all of our targets.

One alternative was the usage of SQS between EventBridge and Lambda. While the SQS & Lambda approach can be useful for tasks that require a more complicated retry logic, for our case a simple lambda function with Destinations is much easier to implement.

Lambda functions which are called asynchronously also have an SQS in the background. AWS takes care of that.

Failed messages can still be sent to a custom DLQ.

We will show you in one of the next posts how we handle retries and failures in detail.

Final Words

This is our introduction to EventBridge and the last one of our basic posts.

Now we will dive deeper into the actual implementation and some nitty-gritty of this architecture.

Posts that will follow soon are:

• Failures & Retries with EventBridge, Lambda, and Destinations

• How to validate incoming events with Middy & ZOD

• Integration tests with EventBridge

Stay tuned 🤘