Deep Dive into Event-Driven Architecture

Last Updated on October 13, 2021 by Editorial Team

Author(s): Gul Ershad

Introduction

The event-driven architecture pattern is a famous distributed asynchronous architecture pattern used to build highly scalable applications. This architecture applies events to trigger and interact among decoupled services and is popular in modern applications developed with microservices. Event-driven architecture can be seen in a shopping cart of an e-commerce website. It carries several events like adding items in the cart, a price change of a product, checkout, payment, shipping, notification of delivery, etc. This kind of architecture facilitates the application to react to changes from a diversity of sources during times of high processing, without impacting the application or over-provisioning resources.

An event‑driven architecture has various benefits. It facilitates the implementation of events that span multiple services and provides eventual consistency. An extra benefit is that it also allows an application to maintain materialized views.

Topology of Event-Driven Architecture

It is important to understand the topology of event-driven architecture to deep dive into various sub-patterns of event-driven architecture. This architecture pattern is based on two main topologies:

• Mediator
• Broker

Mediator Topology

The central mediator plays an important role in mediator topology. It is generally used when it is required to orchestrate various steps with an event through a central mediator. It is helpful for events that have multiple events and needs some level of orchestration to process the event.

Example: Design GPS Programm in a Vehicle

For overall vehicle safety, navigation, and cost estimation plans, GPS data is considered the starting point for designing a proper GPS for a vehicle. They are intended to provide proper business and safety goals. It involves several steps as below:

• Off-Road Vehicle Tracking → An off-road vehicle is recognized to be any type of vehicle that is proficient in driving on and off paved or gravel surfaces. GPS data can provide data of that vehicle and the respective channel will be triggered to analyze further details.
• Travel Time Estimation → GPS provides travel time estimation from one location to another location and this data can be further used to analyze business impact concerning time.
• Navigation to Destination → This is really helpful for logistic companies. Logistics companies implement telematics systems to increase driver productivity and safety. This concept can be used to support route optimization, fuel efficiency, driver safety, and agreement

All these steps would require some level of orchestration to determine the fitness goal steps and that once can be done serially and in parallel.

There are four components involved within the mediator topology:

• Mediator
• Queue
• Channel
• processor

Mediator

The mediator component acts as an orchestrator for every initial step. It identifies the type of event or type of data and sends it to a specific Channel.

Several tools are present to handle mediator topology. Example- jBPM, Mule ESB, Apache Camel, Spring Integration, etc.

Queue

Event Queue is used to carry the event to the event mediator. It is a kind of enterprise messaging queue system. There are several messaging systems like RabbitMQ, Kafka, etc.

Channel

The event channel is utilized by the event mediator to pass particular events related to each step in the primary event to the event processors. It can be either message topic or message queue.

Processor

It is a component or service application that contains business logic for the execution of business needs on receiving of events. Nowadays these are microservice-based components. It can be a channel queue consumer as well.

Broker Topology

In Broker topology, the message flow is distributed across the event processor on receiving of event. It is different from a mediator because it is not central. It is useful in chain types of processing. sup

Example: Design Online Food Ordering System

Online food ordering is the process of ordering food from a website or an app. Whenever a user orders food online from an app or website then it generates an event and message flow to different events to complete the ordering process. It is a kind of chain of different flows:

• User selects restaurant and orders food.
• Pays for the ordered food.
• Restaurant receives notification
• Delivery partner receives notification
• Restaurant handovers food to the delivery partner
• Delivery partner delivers food to the user

In the above architecture design, chaining is available to meet business functionality. Queueing mechanism is also introduced to make it more scalable and precise. This kind of topology is common when an application is evolving or providing for future functionality and extension.

Conclusion

Nowadays event-driven architecture is very popular due to its high scalability and distributed asynchronous behavior. It is a great fit in a microservices architecture and provides a highly decoupled system.

Software Engineering was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Published via Towards AI