Introduction to Event-Driven Microservices Architecture on AWS

The problems with a monolithic architecture

Today, it is very common for software development teams to choose microservices as their design pattern rather than a monolithic design. This is mainly because, in monolithic architectures, all processes are interconnected and run as part of a single service, which leads to a number of problems, including the following:

1. If a particular process has a spike in demand, the entire architecture has to be scaled to make sure it keeps working properly.
2. Adding new processes or features becomes tedious as the codebase grows, which in turn makes it harder to implement new ideas and to experiment, because of the tight coupling between components.
3. If a process fails, the application's availability can be seriously compromised because of its dependencies on the rest of the system's processes, potentially causing a cascading failure.

Microservices: advantages and differences from the monolith

In microservices architectures, by contrast, each microservice is an independent system designed to perform a specific function within the system as a whole, and the different microservices communicate through an interface defined by an API. This allows us to update and scale each microservice independently, that is, without affecting the other microservices.

manuelzapata.co/wp-content/uploads/2018/11/monolito-vs-microservicios.jpg

Drawbacks of using microservices

But it's not all upside: the microservices architecture also has a number of drawbacks that stem from its nature. Because a microservice is an independent system, it will very likely have its own database, and some operations may require more than one microservice, so we need some mechanism to ensure data consistency across the different microservices. While it is true that the defined API interfaces allow us to establish communication between microservices, this is not the best option, since these relationships can become fairly complex as the codebase scales. To solve this problem, there is what is known as Event-Driven Architecture (EDA).

This design pattern establishes that every time a microservice's database is updated, the microservice publishes an event, and the other microservices that need to update their data or perform an operation subscribe to that event. As you can see, the main advantage of this pattern is that it ensures data consistency across our application's microservices without having to use distributed transactions.

Let's look at an example. Suppose we have an application that sells products, and each user has a shopping basket where they add all the products they want to buy. One way to organize all the features this application needs could be the following:

miro.medium.com/max/1400/1*WK_-gPDoCp29u8_MfStF7g.png

The image shows the microservices pattern together with Event-Driven Architecture implemented in the Amazon cloud (AWS).

Users can add 'n' products to the basket and, whenever they choose, check out their entire basket, pay, and the products are theirs. When we want to perform that checkout, several operations have to take place across the different microservices. First, in the product service, we have to reduce the availability of the selected products. Next, we have to empty the basket in the basket service. Finally, we have to confirm the payment and create the order in the ordering service. Without EDA, we would have to perform all of these steps when confirming the checkout. But with EDA implemented using AWS EventBridge (which we'll cover later), it is as simple as publishing an event on a specific bus at checkout. The services affected by this operation then need to add functionality to listen for that event and take the appropriate actions.

Event-Driven Architecture on AWS

AWS offers a service called EventBridge, which, to quote the official documentation, is an event bus that makes it easier to build event-driven applications at scale using events generated by your applications. As AWS explains, EventBridge offers the following advantages:

1. The ability to build event-driven architectures.
2. Writing less code
3. Lower costs, because you only pay for the events generated and don't have to pay to maintain any servers.

Here we can see what EventBridge looks like at the structural level in AWS:

As the image shows, EventBridge provides a serverless event bus that makes it easier to implement event-driven applications.

Events are simply JSON objects that contain information about changes that have occurred in other services. Here is an example of an AWS event generated when an EC2 instance is terminated.

{

"version": "0",

"id": "6a7e8feb-b491-4cf7-a9f1-bf3703467718",

"detail-type": "EC2 Instance State-change Notification",

"source": "aws.ec2",

"account": "111122223333",

"time": "2017-12-22T18:43:48Z",

"region": "us-west-1",

"resources": [

"arn:aws:ec2:us-west-1:123456789012:instance/i-1234567890abcdef0"

],

"detail": {

"instance-id": " i-1234567890abcdef0",

"state": "terminated"

}

}

However, not all of these fields are required when creating an event in AWS. The only required ones are:

1. Detail-type: A string containing the event type.
2. Source: A string containing the origin of the event. These can be events predefined by AWS or custom events.
3. Detail: Useful information about the event in JSON format. It can be empty “{}”.

Conclusions

In this post, we have covered the main differences between a monolith and microservices architectures, as well as the improvements EDA brings to them. Finally, we looked at the services AWS offers to implement EDA and the basic structure of EventBridge.