The C-suite checklist: Event Driven Architecture

Top 5 considerations before you make a move to EDA

What is Event driven Architecture?

Event Driven architecture or EDA is a form of asynchronous communication between two independent or decoupled systems. The communication between two services happens in the form of events.

Put simply, an event driven architecture votes for parallelism where any action or change done by one service or application is published as an event for all those connected who can choose to act in turn. This ensures better performance.

The most basic way this information exchange happens is through the publish/ subscribe model. Here a publisher/ producer publishes events that are to be processed and subscribers of this message will consume it and act accordingly.  This is a better way to approach than the request and response architecture where action is taken only when a service or application requests certain information from another that is expecting that very request.

Top 5 considerations for Event driven Architecture (EDA)

As part of the C-suite you will need to be absolutely convinced to make a move to EDA, instead of endless presentations I thought I would just put across the who, why, and when and you can choose if you need EDA now or needed it yesterday.

☐ Consideration No 1# Who needs EDA?

If you have an extremely large and complex business process involving decoupled components, then you should consider EDA.

☐ Consideration No 2# Why you need EDA?

If you are looking to better your application performance and make user experience more interactive and engaging, then three letters for you: E-D-A.

Something like this:

• better user experience, interaction, and engagement
• greater performance
• efficient caching mechanism

☐ Consideration No 3# When should you consider EDA?

When you have complex and long running external components and your application or services execute multiple external services parallelly – say yes to ‘EDA’.

☐ Consideration No 4# How to adopt EDA?

Typically adopting EDA can happen in a few simple steps:

Step 1: Identify independent complex business components

Step 2: Implement queuing mechanism to publish messages

• Step 2.1: You can have a publisher implementation to put the messages into a queue
• Step 2.2:  You can have a subscriber framework that subscribes messages from the queue and processes those with the respective business component

Step 3: Integrate messages processed in the queue into single place for better user engagement

☐ Consideration No 5# What are the use cases for Event driven Architecture (EDA)?

Usually, it is always business who have a lot of real-time data at play daily who can benefit most out of EDA.

I have chalked out a few examples for you to understand where your organization could use EDA most effectively.

Scenario 1: Integrating apps  

One scenario is when you want to integrate your applications with each other seamlessly.

Let’s imagine that you have legacy systems with data spread across various geographies and external sources consumed through different APIs relying on point-to-point communication. You need to move to EDA if your focus is to be agile and responsive to your customers.

Here is a simple example of implementing EDA for API calls:

You can use queuing with the publish/subscribe model and follow the Asynchronous function framework.

This framework has metadata driven inputs, helps publish long running external APIs calls into a queue. The async function subscribes and processes these calls, and finally once the processing is complete, it will notify the UI using SignalR.

Scenario 2: Integrating decoupled systems

Another scenario is if you are looking to connect multiple devices for either data ingestion or analytics purposes.

Let’s say you have an application that interacts with multiple external APIs to be able to draw intelligent insights for you. And you have ten different insights you need to receive from these external sources and display it to the user. Come to think of it, getting all these insights on a single page with serial execution is bound to be time-consuming and cumbersome.

With EDA, how does your game change? You can achieve what can be called a parallel execution for all these insights. You can notify the UI as and when each insight is ready to be displayed. This means all for the price of one!

Scenario 3: Simulating background jobs

A third scenario I would like you to picture is if you decide to utilize EDA to batch process background jobs.

This time what you are going to be doing is processing bulk requests and sending email notifications on a weekly basis. Anyone around who has great regard for a bot that does all the heavy lifting – then EDA come very handy at times like these.

With EDA the job becomes just about publishing the requests in a queue and waiting for the subscriber to process it parallelly and send email notifications when done.

So, if you ask me, my two cents on EDA are simple – time and efficiency can go hand in hand only when you have things being handled the right way. Get your team to filter out what makes the most sense to have an optimized business process – go with the (event) flow and you will win!

Talk to us if you are considering investing in EDA, and if you would like to know more about the services Nitor Infotech has to offer then visit our website.