What is Event Driven Architecture?

Event Driven Architecture Table of Contents:


Event Driven Architecture (EDA) Explained

Ideal for real-time product creation, highly resilient thanks to loose coupling of services and wide distribution of processes, event-driven architecture (EDA) is becoming more and more popular among today’s software developers.

But what is EDA? It’s not a new language. It is, however, a new programming approach. Perhaps a few everyday examples of what it is and is not will best serve to illustrate.

Event Driven Architecture Example

You’re in the lobby of a building but you need to be on the 20th floor. You press the button that calls the elevator which then travels down to meet you, opens its doors, welcomes you in, and then takes you to the floor of your choice where it opens up and lets you out.

Pressing the button produced the event. The event listener, the elevators operational system, processed the request sending it to the event consumer, the elevator car itself which then processed the trip from the ground floor to the 20th. Nothing at all happened until the event of pushing the button happened.

Note that the button never knew anything about what the elevator did or whether it was successful or not. Nor did it care!

Traditional Request Driven Architecture Example

You’re driving with your young family to a far-off destination. Not long into the trip one of your children asks, “Are we there yet?” You answer “no.”

That same child asks “Are we there yet?” again a few minutes later and again you answer “no.”

The next time the child asks you simply don’t answer. In fact you don’t answer the next several dozen times the child asks.

Finally you reach your destination and turn around waiting for the question to be repeated one last time. The child quietly mumbles, “Are we there yet?” and this time you answer “Yes!”

As opposed to the event of pushing the button triggering the action, your child was polling you periodically to see if the desired result was available yet. You continued processing until your destination was reached at which point your response to the poll was positive.

Characteristics of Event Driven

The first advantage of Event Driven Architecture (EDA) becomes immediately clear. The polling, in this case, was annoying. In systems the polling is simply expensive and burdensome, consuming bandwidth and cycles usually with no result. In fact, EDA service provider Zapier estimates that 98.5% of polling processes are valueless.

One of the most popular modes of EDA is pub/sub in which a service is published making it available. Event producers subscribe to this service and trigger events as needed. Response to order happens in real time providing significant competitive advantage.

Other advantages include:

  • The event producer, event notification, event router, event listeners, event consumers, and event processors are all loosely coupled and widely distributed so the failure of one does not cause others to fail.
  • In fact, the event router acts as an elastic buffer storing events during workload surges or failure-driven delays. Each request is then processed as soon as its listener and consumers are back online demonstrating how fault-tolerant this programming approach is.
  • Because the event router is centralized also stores information on every event it is fairly easy to trace back and identify where a process may have gone wrong. This facilitates auditing, policy definition and enforcement, and coordination between event producer and consumer services.
  • No custom code is ever required to poll, filter, or route requests. Development is accelerated thanks to the event router.
  • EDA enables tremendous horizonal scaling. A single event may trigger many responses resulting in a wide variety of results. The creation of real-time products is significantly enhanced.
  • Most all processes are asynchronous allowing for potential latencies elsewhere.

When Should You Use Event Driven Architectures?

EDA has found application in a wide variety of use cases including real time analytics, fraud detection, sentiment analysis, business process monitoring, real-time personalization of user experience, healthcare monitoring, Medicaid Management Information Systems, IoT applications, trading floors, online shipping, and more.

Placing an order on an eCommerce website in an event that triggers many activities occurring in parallel. Products are picked. Shipping containers are prepared. Bills of lading and other documentation is printed. Order confirmation is sent. Then products are shipped, receipt is confirmed, invoicing occurs followed by receipt of payment. After the event of placement of the order the rest may easily be completely automated.

Where are Event Driven Architectures (EDA) Used?

The past few years have seen several EDA services introduced primarily to the consumer audience. One example is the IFTTT.com service, an acronym which stands for “If THIS then THAT.” Users authenticate a wide variety of internet-based services they use. The “THIS” becomes an event on one service that triggers the “THAT” to occur on the target service. Simple applications including operating lights, doorlocks, and more on voice command, having all household lights and appliances shut down when a specific time of night is reached. Newer services alert emergency services when sounds like glass breaking, fire alarms going off, and other potential emergencies occur.

Moving more toward the business market is Zapier which functions similarly but offers a wider variety of available business-oriented triggers and responsers.

Event Driven Architecture and Microservices

Event Driven Architecutre (EDA) aligns well with the increasing popular use of microservice architectures. Events never travel, they just occur. Everything else needs to be portable. The more each service can stand alone, the more resilient and fault-tolerant the system is. The economies of this programming approach create the likelihood of greater adoption in the field.

 


Event Driven Architecture Table of Contents: