Event Driven Architecture is a widely used architecture for integrating applications and systems. Event-Driven Architecture works by transferring data from Event producers to Event consumers based on the events of subscriber’s interest. EDA based solutions have various benefits including decoupling of producers and consumers, improved performance, better resilience, better scalability etc. In this EDA Introduction tutorial, I have discussed Event Driven Architecture Basics. Event-Driven Architecture advantages have also been discussed in this tutorial.

Even-Driven Architecture Basics: Understanding How Event Driven Architecture Works

Before we dig deeper into EDA (Event-Driven Architecture) and explain how EDA Works, let’s first talk about the basic building block of EDA–The Event itself !

Event-Driven Architecture: What is an Event?

An event is simply a change of state for any object. Change of state triggers an event which contains an event payload with all the necessary details about the specific event. An event can get triggered based on a variety of actions which can be internal or external factors.

Some of the examples of Events in typical business scenarios can be as below:

• A new order is placed in Order Management System.
• A customer’s record is updated in a CRM System.
• A new payment is received in a billing system.
• A fraudulent activity has been performed in a transactional system.
• A threshold limit has exceeded in a measurement system,

Now that we have discussed briefly what the events are; let’s proceed discussing Event Driven Architecture.

Event Driven Architecture Introduction

Event-Driven Architecture is  a software design pattern in which decoupled applications and systems can communicate with each other to transfer data in  asynchronously fashion through publish and subscribe mechanism. In EDA, events are triggered from event sources to event sinks via an event broker (modern messaging-oriented-middleware).

In Event Driven Architecture the key players involved are:

• Event Producer
• Event Consumer
• Event Broker

Event Driven Architecture can opt for either of the two models: Pub-Sub Model or Event Streaming Model.  Events are generated by the Event Producer based on state change. These triggered events are sent to a broker which can be either a traditional MoM (Message Oriented Middleware)  like JMS, ActiveMQ, RabbitMQ or it can be some Event Streaming application like Kafka. In the broker, events reach to certain topics and then those events are subscribed by the consumers based on their subscription interest. Same event can be consumed by multiple consumers as per their requirements.

Event-Driven Architecture

Advantages of Event-Driven Architecture

• Contrary to a traditional SOA based request-response architecture; Event-Driven Architecture provides a great level of decoupling between source & destination applications. The two applications work independently and not blocked by each other. The communication works in asynchronous fashion.
• In Event-Driven architecture, all the powers of a middleware can be rightly exercised including a better error-handling, re-delivery, priority settings, messages persistence etc. This significantly improves resilience as well.
• Event driven architecture brings efficiency and better throughput due to its asynchronous messaging model. Additionally, the network traffic can also be significantly reduced contrary to typical request-response messaging. Only specific and relevant payload is transferred in the event and subsequent service calls can be considered for additional details separately.
• Event-Driven Architecture is highly scalable and distributed. Such an architecture can help dealing with any type of integration requirements with a right topology in a clustered environment.

In the following video on TutorialsPedia YouTube Channel, I have discussed Event Driven Architecture in more details.

Ajmal Abbasi

Ajmal Hussain Abbasi is Integration Consultant By Profession with 13+ years experience in Integration domain mainly with TIBCO products. He has extensive practical knowledge of TIBCO Business Works, TIBCO Cloud, TIBCO Flogo, TIBCO Mashery, TIBCO Spotfire, EMS and TIBCO ActiveSpaces. He has worked on a number of highly critical integration projects in various sectors by using his skills in TIBCO Flogo, TIBCO API Management (Mashery), TCI, Tibco Designer, TIBCO Business Studio, Adapters, TIBCO EMS, RV, Administrator, TIBCO BE, TIBCO ActiveSpaces etc. Ajmal Abbasi has experience with MuleSoft ESB as well. Ajmal Abbasi is also experienced in the area of API Management particularly with WSO2 API management platforms. Ajmal Abbasi is also experienced in developing solutions using Core Java and J2EE Technologies. You can contact Ajmal Abbasi for Consultancy, Technical Assistance and Technical Discussions.

More Posts - Website - Facebook - LinkedIn - YouTube