Hello, folks how are you?
Here again with a new topic - event-driven architectures 🚀
If you enter the world of microservice-style architectures in the cloud you are confronted sometimes with the terms like:
the list can be growing. But from my perspective at the heart is the concept of event-driven systems. What it means event-driven and where do we start? First I give you the counterpart of this style of architecture the synchronous microservices and introduce you further into the world of asynchronous events.
Synchronous microservices?
If you start developing apps most of the time we architect our system around the concept of synchronous invocations.
Suppose you have an upstream service "Shopping Cart" and three downstream services "Billing", "Warehouse" and "E-Mail". In a synchronous style of development, the upstream-service calls directly the downstream-services and waits until the result is received.
But wait what's the problem with this style? The problem is in tight coupling which can produce crazy spaghetti code 🤯.
some further drawbacks:
receiver failure, what if Billing Service breaks?
throttling of downstream services, what if Analytics Service doesn't respond timely
scalability issues, the ability to scale up your one service depends on the ability of all dependent services to scale up
API versioning and maintenance of multiple versions can be very complex due to dependent services => we need some orchestration
Our Solution: Event-driven architecture
Let's first understand the word "Event" here:
"An Event is something that happened in the domain that you care about."
An event in the domain of e-commerce can be an OrderPlaced Event.
It has some important characteristics:
it tells a fact
it's immutable
observable
Event storming is a powerful concept where you model your business processes around events and identify microservices.
But what do we do with these events in order to build architecture?
We asynchronously communicate the events as messages between our microservices. In asynchronous communication, the service which produces the event publishes it in our infrastructure, and other interested services can consume these events.
This brings some advantages compared to synchronous style:
But enough theory, we enter some practical AWS services.
What offers AWS?
AWS offers you many solutions for building event-driven architectures. EventBridge is one of the popular services, where we start our event-driven journey.
According to AWS: "Amazon EventBridge is a serverless event bus that helps you receive, filter, transform, route, and deliver events."
What is this Bus in EventBridge? 🚌🚌
They mention here the concept of bus. Simply EventBridge stores all the events on the bus. Your account has one default event bus, which receives all the events from AWS services in your account. Yeah, that's very cool, AWS is built around an event-driven architecture 🚀 When you start your event-driven architecture journey first you create your custom event buses to receive events from your custom applications.
Ok, let's hack into the AWS console, go to the console and enter EventBridge.
You will create a custom EventBridge
You will create a new rule in Amazon EventBridge.
You will see a sample event in JSON
You will configure this new rule to send it to a Lambda function target
Events in EventBridge?
Ok, EventBridge is an amazing serverless bus where your events in JSON format are stored.
Here bellow is a sample event in JSON format that's EventBridge conform. The red box is the envelope and contains information about which service published the event, the type of event, account, timestamp, region, etc. The blue box contains the actual event payload.
How do we deliver events? 🔔
Our interested services are notified via rules which must be set up in EventBridge. A rule matches incoming events and routes them to targets for processing. A single rule can route to multiple targets, all of which are processed in parallel.
For example, here we catch all events from the service com.aws.orders:
How do targets get called? 🎯🎯
After evaluating the rule the registered targets are called automatically. The targets must be set up after we create the rule. The target service can be a for example Lambda function that writes the order to DynamoDB.
In the end, we have the following architecture:
Real-World example:
What I love about AWS and the community is the amazing blog and of course, the labs provided by the workshops. If you are also a pragmatic programmer, I suggest you try this amazing workshop. In the end, you end up with a fully working event-driven architecture below. Many AWS services react during events flow in the system like StateMachines, API Gateways, etc.
Conclusion
In this first post, I want to give you a high-level overview. In further posts, I plan to go deeper into the landscape of asynchronous event-driven style.
I highly recommend watching the session from Amazon CTO Werner Vogels at re:Invent 2022. He talks about why event-driven architectures enable global scale and why the world is asynchronous in nature 😀 Further he also referred to the Distributed Computing Manifesto, a document from the early days of Amazon.
