Understanding the Event-driven Architecture

Ref. https://softobiz.com/understanding-the-event-driven-architecture/

Varied approaches have appeared recently in computing like big data, serverless, microservice architecture, event-driven architecture, etc. Companies like Netflix and its contemporaries are using these approaches.

For their application development, Microservice architecture plays a major role. But how do they benefit from microservice architecture if the services are not wired? How a single microservice can work on its own?

One of the ways to do this is Event-driven architecture. This software architecture paradigm promotes the production, detection, consumption of, and reaction to events.

The event-driven architecture is a design pattern in which application data is defined as a stream of events. This streaming of data uses various mechanisms like message queues, enterprise service bus (ESB), most recent being Apache Kafka.

This diagram explains the event-driven architecture in detail:

What is an Event? 

Simply put, the event is a significant change in state, which is triggered when a user takes an action. For example:

• When a customer buys a car and its state changes from For Sale to Sold is an event.
• After a successful transaction, when an amount gets deducted from your account is an event.
• Once clicking on the book cab button, when a cab is booked from your account is an event.

Every event may trigger one or more than one options in response.

How is event-driven architecture different from the request-response model?

Event-driven architecture components

An event-driven architecture typically consists of four components:

1. Event

The significant change in the state of an object that occurs when users take action.

2. Event Handler

A software routine, which handles the occurrence of an event.

3. Event Loop

Event loop handles the flow of interaction between an event and the event handler.

4. Event Flow Layers

The event flow layer is built on three logical layers: Event Producer, Event Consumer, and Event Channel (also called Event Bus).

Producer which is responsible for detecting and generating events.

Consumer which consumes the events produced by the event producer.

Event Channel which transfers events from the event generator to the event consumer.

Technologies Used in the Event-driven Architecture

There is no specific development framework for developing an event-driven architecture (EDA)-based app. Instead, developers integrate solutions from different technology providers.

Here are some of the technologies we primarily use for developing an EDA-based app:

1. For Event Capturing

Dell Boomi, Snaplogic, MuleSoft, Dataflow, Apache Apex.

2. For Routing

RabbitMQ, ActiveMQ, Apache Kafka.

3. For Event Processing

Apache Storm, Azure Stream Analytics, Amazon Kinesis, Apache Flink.

Advantages of the Event-driven architecture

• Adding new events and processes is very easy in the event-driven architecture.
• You can quickly roll-back changes or move to any event in the event-driven architecture. Doing so proves helpful in case any issue occurs.
• Event-driven architecture also gives you the transactional guarantee, i.e., you re notified of every successful transaction that occurs.
• The architecture is versatile and easily replaceable.
• EDA  is highly responsive. Instead of waiting for issues to occur, you can easily detect them in advance – thus ensuring that the app keeps working.

Important Things to Consider

The event-driven architecture offers spectacular benefits. However, it is very complex to implement. There are a lot of essential things that your mind need to consider while implementing the architecture, such as:

1. Complexity will Increase

As EDA systems are loosely coupled and highly distributed, it’s hard to know which event is connected to which microservice and what is the dependency between them. It makes understanding the flow of events in the architecture can be tricky. You never know when even a small change can result in an unforeseen chain of reactions.

2. There’s Not Much Control in the Event-driven Architecture (EDA)

We don’t really have much control or visibility over events in the Event driven architecture. It’s not clearly defined which event should be consumed and which shouldn’t. Maybe, there are some actions that you don’t want to publish, such as a transaction failure or some bug.

Now, how would a microservice know that it doesn’t have to publish this event?

This way, the architecture adds an extra layer of confusion.

3. Certain Events can’t be Undone

While you can easily roll-back changes in EDA, there are some events which you can’t undo. It’s simply not possible because the event is dependent on an external system. For example, you can’t unsend an email that you just sent.

For this reason, we use Zeebe and Kafka to increase control and reduce complexity by orchestrating the events.

In a Nutshell

The benefits of event-driven architecture are spectacular. But there is also another side to it that you can’t ignore. Unless you have high-level expertise and you are considering all of its critical factors in mind, your decision to use EDA can backfire. We have experience working on the event-driven architecture. So, we can offer you the much-needed guidance. Contact us to know how to get started.

•  Event-driven Architecture, Microservice Architecture, Microservices