Overview:
Event-Driven Architecture (EDA)
Event-Driven Architecture (EDA) is a design pattern that orchestrates the behavior of distributed systems through the production, detection, consumption, and reaction to events. An event is a significant change in state, such as an item being placed in a shopping cart or an order being shipped. EDA promotes loose coupling between services, allowing for independent scaling, failure resilience, and complex workflow simplification. It enables real-time data flow between decoupled services, making systems more responsive and efficient.
Synchronous Communications
Synchronous communication refers to real-time interactions where information is exchanged immediately between parties. This method is essential for discussions that require immediate feedback or resolution, such as negotiations, decision-making processes, or emergency responses. It’s characterized by direct, two-way conversations that can occur in person, over the phone, or through video conferencing.
Asynchronous Communications
Asynchronous communication involves the exchange of information without the expectation of an immediate response. This approach is beneficial for distributed teams across different time zones, allowing individuals to contribute at their convenience. It encompasses a wide range of tools and platforms, including emails, message boards, and shared documents, facilitating a flexible and uninterrupted workflow.
Let’s now describe what an event-driven architecture means for our microservices solution, and how it would look like.
Event-driven architecture is all about enabling asynchronous collaboration between microservices.
Synchronous Communication:
If contrast with the synchronous communication pattern that we can easily implement between two or more microservices the main problem with this pattern is that when you directly communicate to a service from another service it creates a temporal coupling between those two, and any kind of coupling is precisely what we would need to avoid when building robust and scalable microservices applications.
We should always strive for autonomous services that could be deployed in isolation without impacting other services.
The truth of the matter is that if a microservice relies on another to fulfill a request then it isn’t truly autonomous. As you could imagine, the problem worsens when more than two microservices are involved in the same chain of requests.
For example, what happens in this scenario if Service C fails?
It’ll create a domino effect that goes back to the original caller.
Asynchronous communication between services based on events
That’s precisely why most of the time it’s a better idea to have asynchronous communication between services based on events. In this architecture we always have three main elements, event producers that create events. These events originate from the domain logic of the application.
Oftentimes the event producers are not aware of which components or services are interested in receiving those events. The second element is indeed the event consumers, and the third element is the event broker, platform, or application that we use in our system. There are so many different products in this category and all of them have the same goal, to enable loosely coupled communication between services. To accomplish this the event consumers subscribe to a particular event or set of events that they are interested in. When the event publishers actually publish one of those events the consumers receive the event and its related data.
In this fashion we could have dozens, hundreds, or even thousands of microservices receiving events in a loosely coupled way. This is one excellent way to achieve true autonomy. As I’ve already mentioned, there’s an abundance of platforms and products that perform the same goal of asynchronous sending and receiving of events.
Event-driven Architecture:
We’ll use Azure Service Bus here.
Technically we provision an Azure Service Bus namespace, and inside the namespace we create topics. We could also create queues, but that’s out of the scope in this course.
After creating the topic we create a subscription for that particular topic.
Then our microservice application communicates to the subscription to publish or consume the events. Now it’s the perfect moment for you to provision your Azure Service Bus namespace that you’re going to use in this course.
Please be sure to create the topics and related subscriptions.
There are two other concepts, domain events and integration events.
Both of them are essential topics in domain-driven design, and we use them a lot in the accompanying code of this course.
Both the main and integration events represent facts in the domain logic. In other words, something that happened in the past, something unchangeable.
The difference is in the way that we handle those events.
For instance, domain events are handled in process and trigger side effects in the same domain whereas integration events are handled out of process and trigger side effects in a different domain.
Additionally, domain events are created in the core domain layer whereas integration events are created in the application layer. Of course, there could be many different ways to implement them. However, this is the way they’re implemented in the code.
Domain Events vs Integration Events
Conclusion
Incorporating EDA, along with synchronous and asynchronous communications, into a system’s design offers a robust framework for handling the dynamic nature of modern applications.
EDA provides the agility needed to respond to real-time events, while synchronous and asynchronous communications ensure that teams can collaborate effectively, regardless of their location or time zone.
Together, they form a comprehensive approach to building scalable, resilient, and efficient systems suitable for today’s fast-paced digital environment.
This integration of communication styles and architectural patterns is crucial for businesses looking to stay competitive and agile in the ever-evolving technological landscape.