Evolving Your System by Implementing Event-Driven Architecture (EDA)

Real-time is no longer a “nice-to-have.” Sensors deployed in the Internet of Things (IoT) are detecting events happening that require a rapid response either from another machine or sometimes from a human. The expectation that everything will interoperate with everything is no longer an assumption, its a requirement. You can implement event-driven architecture (EDA) to achieve it, but that imposes the challenge of changing the way you think about systems.

EDA enables real-time notification and response for every event happening within a system, or event within associated systems. Instead of waiting for a command or request to be issued, EDA is constantly vigilant awaiting any of a large number of events to occur. When they do, a notification is sent to an event processor that takes appropriate action in response to the event. With an event router, multiple responses may be triggered. Also, multiple events happening at different times in different places may be combined to trigger response once they all achieve their necessary states. The difference between a command and a triggering event is simple to visualize. You walk into a room equipped with a motion-detector light switch. When you do, the event of your entry is detected, the control for the light is notified and it goes on. That’s an event. Alternately, had you had to flip a switch to turn the light on, that’s a command.

Evolving to an Asynchronous, Reactive Model

The word reactive carries something of a negative connotation. Everyone wants to be proactive, right? But in the case of the evolution of application development that’s exactly where we want to go.

Traditionally, developers were trained to think in procedures. Remote procedure calls (RPC), synchronous function calls, web services, APIs, and service-oriented architecture (SOA) were the underpinnings of how applications were designed and built. All were synchronous, issuing a command complete with necessary data and metadata. All functions were tightly coupled to each other, so modification was a substantial undertaking. Each had awareness of each other, each command expected a response. The fact that all code could easily be traced in the event of a malfunction was helpful, but synchronous systems were difficult to scale.

EDA is loosely coupled and asynchronous. Events may be sent directly to an event broker or mediator depending upon the complexity of the response required. Where a command requires a response, an event may or may not trigger a response, or the event processor may need to wait for all involved events to occur before taking action. None of the components of the architecture are aware of each other. Instead of sending a message and awaiting a response, all they do is send. The separation of every function makes it far easier to upgrade and improve components of the system without having to take the entire thing down.

Getting Started with Implementation of EDA

Anyone implementing DevOps quickly learns that the most important task is to develop a DevOps culture within the organization. Anyone participating will need to change the way they approach the design and architecture of solutions. They must trade in the long-conditioned tendency to see everything as a sequence of requests, process, reply, confirm. There will be no more program calls, requests, declarations, or invocations. There will be events that require processing, and responses that will often need to be produced.

As you shift paradigms from request-driven to event-driven you’ll also shift your approach from one of orchestration to one more closely resembling choreography.

The difference is simple. Orchestration tightly controls everything, all components, all interactions, remaining involved in each until it is completed. As you can imagine, that won’t scale readily as the orchestrator must await a response from each service it initiates before proceeding. Choreography provides patterns and routines that services follow, and it is expected they will do so without supervision or further instruction.

Tracking the flow of an EDA system is almost impossible since there is no set sequence of events. What happens in the system depends upon events taking place elsewhere in the system, or externally. The same is true for planning an EDA solution. Anything that can occur within your organization must be seen as a digital event. Every operating process is a series of events. There are no recursive loops for confirming activities.

Planning for Implementation

The planning process concerns itself with identifying the events that may happen at any given point and mapping the required responses to each under whatever combination of conditions they may occur.


EDA will require that you decompose your existing workflows into microservices and implement runtime fabric that supports the ability of these to communicate in EDA’s preferred publish/subscribe (pub/sub) fashion capable of distributing to many potential destinations.

Required runtime and design components include:

  • Event Broker: The most basic component for event routing in a pub/sub, providing low latency and guaranteed delivery. Decoupled applications and microservices converse through the event broker preferably using open protocols and APIs.
  • Event Mesh: A network of event brokers for routing events between applications on-premises, in the cloud, or at the network edge.
  • Event Portal: Similar to an API portal provides a view into your event mesh, giving architects design tools that are GUI-based. Defined events, microservices, and applications can also be designed in the event portal.
  • Event Taxonomy: The topic naming convention you design first and use consistently later. A good taxonomy supports event routing. Best to keep the conventions obvious and easily recognizable for developers.

An EDA Pilot to Play it Smart

This is a dramatic change for everyone involved, a change in the fundamental way they think about and approach development, deployment, and operation. Success will depend upon winning buy-in from every group that becomes involved until the entire organization is familiar and comfortable.

For your pilot EDA project, choose something of moderate criticality from which the improvements will be readily observed and experienced. Moving from the comfortably confirmed communications world of synchronous systems to the highly decoupled environment of EDA can feel like a “crossing the chasm” moment. It is strongly suggested that you seek out expert, experienced assistance as you embark on your journey.


We certainly hope you’ll include Tiempo Development in your search for a capable partner to work with on your EDA project. Knowledge transfer and earning our reputation for excellence are our highest priorities. Contact us today to learn how we can help.


Event-Driven Architecture eBook CTA