💔 Decoupling Microservices with AWS EventBridge

Introduction

AWS EventBridge is an architecture changing tool, it will transform the way you think about serverless development. It helps you build event-driven applications at scale across AWS, existing systems or SaaS apps. It shifts you’re thinking on how distributed systems work from a pipeline towards an event-based model.

Event-based processing

So what does that mean, shifting from a pipeline towards an event-based model? On an abstract level, it is not that complicated.

You’re probably used to seeing diagrams like these. A couple of microservices hang around and rely on each other. You depend on requests to kick your business logic, and it sort of works. However, the pain comes when you’re rapidly developing, and you’re consumers are no longer able to catch up with you. The backlog is building, and backwards compatibility is now a thing you’re developers are mentioning in their 1-1’s with their managers. At the same time, developers starting to get blocked by the requests they put into the other team’s backlog, and issues are arising. Lastly, there are pains when needing to cancel something in one of the microservices at the last stages of the process. In this example, how about a payment that was returned thus invalidating a review of a product, how would that work? In comes AWS EventBridge.

Event-based microservices are different because they decouple the microservices even further. Instead of relying on something to call on you actively, you’re listening for events in which you’re interested and respond appropriately. This change in methodology creates the possibility for developers to create microservices that truly offer one piece of core functionality based on an event in the process. They are no longer reliant on whatever else is happening around them.

What does AWS EventBridge do then?

EventBridge accommodates this use case by offering a couple of crucial pieces to the puzzle. EventBridge provides an event bus. The event bus is considered the main attraction. It is where you put any newly generated event by any of your clients.

A great feature that EventBridge offers as part of its bus is the routing feature. Thanks to routing, you’re able to very specifically listen to messages instead of all messages on the bus. The last part of the puzzle is consumers’ action based on the messages on the bus. EventBridge offers a set of AWS services as consumers, but there is also support for custom API destinations, allowing you to route a request to an external party directly.

How would you rewrite a standard set of microservices to an event-based model?

In our case, we are taking a postal service package process as an example.

We have a client, a barcode scanner, that enters a new package into the system. The package then goes through multiple processing stages, from inbound to the postal service until the delivery at the customer’s site. In between, it’s obviously in transit a couple of times, and it needs to go through one or more fulfilment centres. When we take an abstract overview of a package’s lifetime, it will look like the following:

Microservice architecture

Now, if we convert this to a regular microservice architecture as you’d traditionally see, it would look like the following.

We see that we have one ScannerService that accepts the barcode scanner’s request. That ScannerService, in turn, accepts the new package, does some business logic, persists some data in the database, and then goes back to sleep. After that, the PlanningService will have to create the pick-up in the planning for a delivery driver. We see that the first driver picks up the package at the send location after a day. Once he scans the package, it triggers the TransitService, where the same type of business logic applies. As a final step, the package arrives at the fulfilment centre, where it needs to be processed by the FullfillmentService. Before final delivery, we need to plan the package into another driver’s delivery route by the PlanningService.

In this abstract example of four microservices, we are already talking about four dedicated scanners that need to make requests on a specific endpoint. To add to the complexity, if a package got lost at the fulfilment centre, we would need to cancel the planned delivery and automatically contact the customer. Although possible, once created, this functionality would tightly couple the TransitService, FullfillmentService and the PlanningService to accommodate this use-case. While in the end, It’s all part of one functional process flow. This example is a prime candidate where an event-based model would greatly help.

Event-based architecture

So how would we do it differently using AWS EventBridge? First of all, you don’t want to couple any services together. Every service has its responsibilities and responds to messages on the bus. This is not a request-response model, and something you might have to shift you’re thinking on. Your service will take up a task based on someone shouting something on the bus.

Imagine it like this: every time a scanner puts something on the bus, whether that’s creating a new package in the system, scanning a new entry at the fulfilment centre, all the services are listening.

Instead of coordinating with other systems, your consumers or services are executing when they find a message interesting. For example, the FullfillmentService is just interested when new packages arrive at the facilities. If a new message is put on the bus that there’s a new package available, it picks it up and starts processing it. After the service has finished, itself can also put any new message on the bus for any other consumer to pick up.

A consumer that would be interested in listening to messages from the FullfillmentService, for example, would be the PlanningService. Once the FullfillmentService put a message on the bus that the package is ready for delivery, the PlanningService would create planning for a driver to pick up. Simultaneously, an EmailService could pick up the message and send out an e-mail to the customer saying that the package has arrived at the facility and will be arriving at the delivery address in the next 24 hours. The possibilities are endless.

Conclusion

AWS EventBridge had come a long way since its original functionality in CloudWatch events years ago. With the added functionality of custom API destinations and partner integrations, it’s well on its way to becoming the next big thing in Serverless applications. If nothing else, the event model is something to consider when building your next extensive application.

If you’re interested in building out this solution with AWS EventBridge, we have created a technical tutorial on implementing it step by step on our https://www.nbtl.blog. On there, you can also find idea’s, tutorials and information on a range of AWS cloud technologies that can help your business accelerate and build on the cloud.

---

Technical posts

On our blog, we offer lots of other technical posts. Are you, for example:

• interested in building out a 5-minute React deployment with AWS Amplify?
• Or are you looking to build an AWS CDK application that scales ECS based on an SQS queue size?