Event-Driven Architecture (Everything Worth Knowing)
Event-Driven Architecture or EDA is one of the most popular and attractive distributed software architectural pattern. There are many reasons to make it the first or even the best option when we want to choose an architecture style for our project.
The main reason to opt it would be variety of non-functional requirements that EDA offers to developers, like scalability, modularity, high performance and fault tolerance. Beside mentioned advantages of EDA, there are some features such as implementation, testing and error handling in distributed systems which could be challenging because of architecture complexity.
Furthermore, since events play a central role in Event-Driven Architecture, they streamline and standardize communication among software components. This aspect can persuade architects to adopt EDA as a complement to microservices architecture.
Moreover, its great compatibility and relevancy with Domain-Driven Design could be the other reason for popularity of this architectural style. But, what is exactly an Event-Driven Architecture? Strictly speaking, it provides East-West (horizontal) communication pattern between software services and application components via asynchronous communication through events.
Event-driven architecture (EDA) is a software architecture paradigm promoting the production, detection, consumption of, and reaction to events. -- Wikipedia
Event-Driven Architecture Building Blocks
Investigating, interpreting and assessing about specific architectural pattern and its elements and basics has been always an interesting topic in software engineering. In regard to variety of customer requirements and various business constraints, we can employ the same architectural pattern to prototype, finalize and build different products.
The modern Event-Driven Architecture, in general and regardless of requested -ilities , can be characterized with 3 main fundamental elements or pillars.
Event
As it is recognizable from the EDA name, events are the key components of the Event-Driven Architecture. They describe changes in business domains that are named also notifications. In essence, events are the tangible manifestations of both anticipated and unforeseen changes in the states of the various components that make up a software system.
In simple terms, EDA systems typically have 3 types of event patterns to describe changes in business domains that could be divided in two groups as follows:
Status of business domain: This category of events aims to outline the changes that occur at specific time during the certain processes and in Event-Driven architecture, could be represented as notification events and/or domain events. Notification events are generated and sent across the network to be utilized and processed by other components. They are concise and without any detailed description. Domain events, unlike notifications, contain detailed information about the changes in business domain.
State of business domain: Unlike the other category, this type of events provides change description in the condition of business domain at specific time and are know as event-carried state transfer or ECST. They contains all necessary and detailed information that consumers need.
Event Processor
Each building block in software, that is implemented to handle a part of business logic in code-base and participates in the service delivery and software development lifecycle, can play a role as an event processor. They can act as event consumer and/or event producer. Event processors can have various architectures and designs, such as coarse-grained stand-alone monolithic software consists of components and database to perform multiple jobs or fine-grained services that are designed to accomplish only one task. But the most popular pattern, that nowadays is known as the best practice, is microservices pattern.
Event-Driven microservices architecture is the compound architecture that processors are defined as fine-grained standalone services and communicate with each other by sending and receiving events asynchronously.
Message Broker
Broker is the third pillar of Event-Driven Architecture. It is responsible to deliver events to the consumers. In other words, it takes messages from processors (producers) and deliver them to the other(s) building blocks based on event destination and channel type. The biggest advantage of message brokers is the possibility of decoupling services from each other, temporally and functionally. When one service needs to wait for another event processor or be executed before it, they're temporally coupled.
Functional coupling happens when an event processor is calling a function or module from the other event processor. This kind of coupling can easily lead to a mess, distributed big ball of mud.
Moreover, using asynchronous communication style, that is offered by such message brokers like Kafka and RabbitMQ, provides continuous integration and technology agnostic protocol communication between software building blocks in general and between services in microservices architecture and EDA approach.
To gain a better understanding and more thorough insight into message brokers, refer to the Brokers & Queues - Comparison & Contrast in Messaging.
Differences & Similarities
Beside Event-Driven Architecture, Message-Driven Architecture (MDA), Data-Driven Architecture and Microservices Architecture are the other options that may be chosen by architects, based on the business logic and software requirements, to implement and deploy distributed systems.
In this section we're going to take a look at similarities and differences between EDA and the 3 other architectural paradigms.
EDA vs. Data-Driven Architecture: The main difference between EDA and Data-Driven Architecture (DDA) is the way of applying, controlling and changing policies and rules that build and define business logic. In the realm of EDA, the business logic is embedded within the code base (source code). Whereas in DDA, it resides within the data and code does not deal with domain logic at all. Furthermore, in DDA changing data results altering business logic but in EDA, events and their contents consequence the variations in business logic.
EDA vs. Message-Driven Architecture: As a matter of fact, events are subset of messages, both are responsible to provide some information for consumers, and you can think of Event-Driven Architecture as a part of Message-Driven Architecture (MDA). However, the main difference between EDA and MDA lies in how we define what an event and a message are.
Events often get triggered regarding changes in any part of a system, such as data and state. On the contrary, messages are the description of commands that should be executed by service. In the context of Burger-Best, when applying the EventStorming technique for business modeling, it becomes evident that this approach seamlessly blends event-based and message-based methodologies to meet the needs and requirements of certain domains.
For instance in kitchen domain, consider the journey of an order (hamburger(s)) from the moment it is prepared in the kitchen until it is handed over to the delivery department (another business domain), two distinct communication patterns come into play: the message-driven pattern and the event-driven pattern:
MDA: A command is triggered by the chef as an actor to describe finalizing cooking process. The consequence is an event that illustrates the outcome of finalizing command.
EDA: The generated event is going to be resulted to pack the order(s). When the orders are packed, a new event will be published to inform delivery domain.
The other characteristic that helps us to differentiate these two architectural paradigm is the location that message/event should be delivered. The destination of message in MDA is predefined and it is similar to function call but an events tin EDA could be received by any consumer.
EDA vs. Microservices Architecture: Basically, EDA cannot serve as a replacement for microservices architecture since they cater to distinct purposes and fundamentally pursue different objectives. To put it differently, drawing a comparison between them is similar to comparing oranges and apples. Event processors or services within an EDA can vary in size and accommodate different sets of responsibilities as dictated by business definitions and requirements. In contrast, Microservices strictly adhere to the Single Responsibility Principle, with each service being stand-alone. This underscores that service granularity stands out as a fundamental aspect distinguishing EDA from microservices.
Another aspect that may be regarded as a significant distinction between EDA and microservices architecture pertains to data granularity, database schema, and, in essence, the overall handling of data. Each microservice operates with its own separate database, distinct from those of other services. In contrast, within the Event-Driven Architecture, there is a single database schema that all services can access to retrieve or modify data and information.
To put it accurately, EDA data is characterized by a lower level of granularity or is coarse-grained, whereas microservices architecture exhibits a fine-grained data.
Last but not least, the most significant contrast between these two architectural patterns pertains to the concept of "bounded context," as defined within domain-driven design. In the Event-Driven Architecture, it's quite common to encompass multiple services within a single bounded context. In contrast, in a microservices architecture, the bounded context is meticulously tailored to correspond to a single microservices and its associated data.
Exploring Varieties of Event-Driven Architecture
Event-Driven Architecture can be primarily categorized into two main approaches or topologies, Choreography and Orchestration.
Each approach has its advantages and disadvantages. So it's crucial to think about which one suits the distributed architecture style best. This decision should be based on factors such as the domain, business needs, and software requirements (functional and non-functional).
Let's delve into a detailed exploration of both styles to gain a thorough, comprehensive and precise understanding of them.
In software business, the EDA choreography architecture is also known as broker topology. The name itself, choreography, makes it clear that each software component or service acts interdependently without any conducting to accomplish its responsibilities as part of system. In our daily life, this term typically evokes images of group dancing like ballet. And clearly, it is exactly our expectation from choreography architecture in software world.
The diagram presented above illustrates a simple primitive E-commerce application that is based on broker EDA, where components are totally decouple from each other and RabbitMQ is acting as the event router and controller or message broker.
To get a deeper and more detailed understanding of choreography EDA (Broker), please take a look at Event-Driven Architecture -Choreography Topology.
This variant of event-driven architectural paradigm, in contrast to the broker architecture and as implied by its nomenclature, orchestration architecture, comprises services and components orchestrated and managed by a designated component. This specific component, that acts as controller, is responsible to process, manage and route events to the other services or in general consumers. In some product, it could be referred to as the control plane.
The diagram you see represents our E-commerce system we talked about earlier. In this system, RabbitMQ serves as an orchestrator, working like a mediator in Event-Driven Architecture (EDA). The other name for this architectural paradigm is Mediator EDA.
To get a deeper and more detailed understanding of orchestrated EDA (Mediator), check out Orchestrated Event-Driven Architecture .
Strengths and Weaknesses of EDA
Like any architectural pattern, Event-Driven Architecture has its benefits and drawbacks. Here, in the table below, we'll take a closer look at some key advantages and disadvantages of EDA.
Loose Coupling: In technical terms, EDA provide the possibility to maintain a high level of independence among services and minimizing direct knowledge of components from each other, ideally near to zero (that never happens be cause of sharing the same database in most cases!). This capability is mainly offered through asynchronous communication.
Scalability: As service boundaries are characterized mostly based on business requirements and concerns, scaling one service because of any reason like increasing workload would be done totally independently from rest of the system. For example, In the E-commerce system mentioned earlier, during Black Friday, we have to increase the capacity of order processing service significantly, while the notification center doesn't require the same level of scaling
Fault Tolerance: Generally speaking, when a distributed system is fault tolerate, it means it can deal with errors and failures without causing the entire system to crash. As services are loosely coupled, if one of them crashes or fails, the other component should not be affected.
Debugging: Debugging an EDA application, and distributed applications in general, with multiple services is more challenging compared to a monolithic application that offers easy debugging. Additionally, as the number of components in the EDA application increases, the difficulty of debugging grows non-linearly.
Complexity: From the initial planning and design phases to the development, testing, and delivery of distributed system that uses asynchronous events for communication between various components and services to create Event-Driven Architecture software, managing and tackling complexity of ecosystem becomes an ongoing hurdle in such projects. Coordinating and managing services through events, along with software troubleshooting, naturally makes EDA systems more complicated.
Learning Curve: In the realm of creating and implementing EDA systems, having sufficient knowledge and prior experience is crucial. If a team lacks familiarity with such projects, the process of learning about EDA can significantly impact both the development and delivery of the product.
Event-Driven Architecture Use Cases
As mentioned earlier, EDA is a widely used architectural style in various businesses and industries. Let's explore some use cases together.
Fraud Detection: It is a process of detecting and preventing fraudulent behavior and malicious activities which aim to identity and/or information theft, cyber attack or financial fraud that EDA is a well-suited methodology for such complex and business-critical use case. For instance to block fraudulent activities like money laundering in the telecom industry, we can employ Event-Driven Architecture in primitive and simple format combined with rules-engine as logic layer to analyse the received events. Alternatively we could implement more advanced approach that uses supervised and/or unsupervised machine learning algorithms to detect outliers from reported events.
E-commerce: Buying and selling everything online such as service and goods, known as e-commerce, whether it's business-to-business (B2B), business-to-consumer (B2C) online payment, digital marketing and etc, involves many data transaction that are recognized as events. To effectively handle and manage of these events (both received and sent), Event-Driven Architecture is the widely used approach in this industry.
Internet of Things (IoT): This definition refers to interconnected embedded devices, which are known as things, that are spread worldwide and communicating via internet. Communication things with central server, orchestrator, or other devices through events. The management and analyzing of these events is handled by a large-scale Event-Driven Architecture software.
The connected car stands out as the most well-known example, where every component communicates, reports, and provides feedback to a central server that continuously monitors the car's health.
The connected car stands out as the most well-known example, where every component communicates, reports, and provides feedback to a central server that continuously monitors the car's health.
Wrapping Up
In the present era, where things are becoming increasingly intricate and our daily lives are dominated by devices that communicate with each other, it is essential for every software developer and software architect to grasp the skills required to overcome this complexity.
Using Event-Driven Architecture, especially when it is combined with other approaches like microservices, is a commonly used pattern and let's say Best-Practice to tackle the challenges of today's complex needs and come up with practical solutions to meet customer requirements. For a successful design, development, and deployment, it's recommended to approach Event-Driven Architecture in an evolutionary manner. This implies that making adjustments during the development phase will incur minimal expenses and costs.
When it comes to the technical aspects of our project, we need to consider non-functional requirements and what the customer prefers. One decision we have to make is whether to use orchestration or choreography topology, and then design our project accordingly.
Share This Article