Understanding the Event-driven Architecture

On

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:

Event-driven Architecture 2

 

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?

Request response vs Event-driven

 

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).

event-producers

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:

For Event Capturing

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

For Routing

RabbitMQ, ActiveMQ, Apache Kafka.

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 cannot 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.

Undoubtedly, the benefits that event-driven architecture offers are spectacular. Still, for implementing it to its maximum, you will need high-level expertise and Softobiz can help.

Related Posts

Orchestration Made Easy with Zeebe and Kafka
Orchestration Made Easy with Zeebe and Kafka

Orchestration Made Easy with Zeebe and Kafka

Orchestration with Zeebe and Kafka as a workflow engine was approached to encounter the challenges faced by microservices. In other words, shifting from monolith to …

Microservice Orchestration Vs Choreography
Microservice Orchestration Vs Choreography

Microservice Orchestration Vs Choreography

The microservice architecture is a collection of small services with each service having a specific function. These service modules can’t perform well in isolation and …

Microservice Architecture: An Independent Approach to Software Development
Microservice Architecture: An Independent Approach to Software Development

Microservice Architecture: An Independent Approach to Software Development

Skepticism by communities in software development dismisses Microservices architecture as nothing new, just an overhaul of the old SOA (service-oriented architecture). Despite all the uncertainties, …