September 20, 2021
Components of Event-Driven Architecture
Making a request and getting a response is a common occurrence—both in programming and in the real world. You walk up to an elevator and press the call button. The elevator shows up a few seconds later, the doors open, and you step in. You press the button for the floor you’re going to, and the elevator takes you to that floor. Two-button presses, both requests, and two responses from the elevator. Simple.
In an equally simple digital example, you click on a web link that issues a request that takes your browser to the desired web product. And as new applications emerge, especially in the Internet of Things (IoT) space, it becomes clearer all the time that the interactive, interoperable world won’t wait for requests.
“Things” in the IoT tend to fall into two categories: sensors that detect things happening and switches that enable responses to make other things happen. For example, a thermometer may detect that the temperature has risen above 80°F in a given space. Exceeding that threshold is the event. Turning on the air conditioning is the result.
Features of Event-Driven Architectures
First developed almost twenty years ago, Event-Driven Architecture (EDA) creates an environment in which there’s no waiting for requests. Instead, they detect when any one of many various items changes state sufficiently to warrant a response. Then they perform that response. The architecture is asynchronous and distributed.
Events may occur while resources are unavailable to respond to them. EDA makes provision for storing such event notifications until resources become available. It is also highly decoupled. None of the event producers or consumers—or the processors and data transport that connects them—are aware of each other and remain so even after the transaction is completed.
In our air conditioning example, the air conditioner may want to know whether to run on low, medium, or high based on the current temperature. The notification of the event can include specific data about that event, which may be useful in determining how to respond.
EDA is not a specific software language. Rather, it is an architecture, an approach to programming, and a model for a more efficient solution for the capture, communication, processing, and persistence of events. As such, event-driven applications may be created in any programming language. EDA processes are highly-decoupled and can be scaled independently, which makes it a good option for modern, distributed, and cloud-enabled applications that are horizontally scalable and resilient to failure.
Fundamentally, EDA detects something significant and meaningful happening, and then distributes useful information to all humans and automated systems interested in having that information. Those interested parties may or may not take action in the form of launching other services, commencing specific business processes, or obtaining further information.
Extremely Loose Coupling
EDA is extremely loosely-coupled and highly-distributed. The producer of any event only knows the event occurred, with no knowledge of subsequent processing, or even the identity or existence of the interested parties. This loose coupling enables great flexibility but makes tracing errors in dynamic, multi-path, event networks quite challenging. EDA is best used for asynchronous workflows.
Choice of Topologies: Use mediator topology when orchestrating multiple steps within an event through a central mediator. Use broker topology to concatenate events without using a central mediator.
Event Processing Styles
Events may be processed in any of several styles. Mature EDA systems often combine more than one.
Simple Event Processing
Typically used to take latency and cost out of business processes, simple event processing simply initiates action further down the application stream. This occurs whenever a significant and meaningful change of state occurs in any hardware or software component of the system.
Stream Event Processing
Stream event processing detects ordinary events as well as significant and meaningful ones, screening them to determine significance and streaming them downstream to information subscribers. This aids in enabling in-time decision-making.
Complex Event Processing
Complex event processing (CEP) is used when evaluating multiple events and taking action as necessary. The events involved need not be of the same type or even occur at the same time. CEP uses far more sophisticated interpreters, pattern definitions, and correlation techniques. Correlation may be casual, temporal or spatial and is typically used to identify and act on business anomalies, threats, and opportunities.
Publish/Subscribe (Pub/Sub) Processing
Pub/sub simply denotes publishers pushing messages to subscribers. In EDA, pub/sub provides instant event notifications for distributed applications. Given the extremely loose decoupling of EDA, this is especially useful in distributing event information to many separate systems.
Event-Driven Architecture Flow Layers
Since EDA is a software development architecture, it exists as a series of flow layers made up of components, each of which plays an important part in application design. The sequence of an EDA event flow consists of four fundamental layers that contain multiple components:
Event Channels
An event channel is a messaging backbone that transports events in a standard format between event generators, event processors, and downstream subscribers.
Event Processing
Actions taken by event processing are based upon an evaluation of each event against established processing rules. Possible actions include the invocation of a specific service, launching of a business process, the publication of the event to subscribers, generation of another event, or simple storage of the event.
Event-Driven Downstream Activity
Events may initiate a variety of activities downstream. For example, commencing a service or business process may be pushed by the event processing engine while subscribers may pull event publications as needed. Possible subscribers include applications, data warehouses, automated agents, active business processes, dashboards, and humans.
Event-Driven Architecture Flow Components
Although EDA has been in use for almost two decades, there are still many varying descriptions, definitions, and nomenclature. In the following components list, great effort has been made to include as many different names for each component as could be found.
What things are called is not nearly as important as how they work together to enable software to effectively respond to a wide variety of events that happen internally, externally, and in the “real” world.
These components are presented as close to the sequence in which they are involved as possible:
Event
In common programming parlance, the basic attributes of an event include time, source, key, header, metadata, and payload. In terms of EDA, an event is simply a significant and meaningful change of state in an object and any specific data that may be relevant to it. That data is often referred to as the event payload.
The object need not be aware and usually is not aware of any of the other components in the EDA system. Put simply, it just does what it does.
Users may be the source of an event when they press a key or click a mouse. Sensors may detect an event in the physical world and generate an event as a result. The system itself may generate events too, such as when software is loaded. An event may signify a problem, an opportunity, the crossing of a threshold, or some other deviation from normal. Significant and meaningful events must be specified and evaluated in business terms rather than data or application terms.
Event Producer (Generator)
Every event is generated from a source. The source might be an application, data store, service, business process, transmitter, sensor, or collaboration tool (IM, email). An ordinary event may be evaluated for notability by an event preprocessor (router, filter), resulting in the generation of a new notable event.
Because of the variety of event generators, not all events will be generated in the required format for event processing. In those cases, the events need to be transformed to the required (enterprise standard) format prior to being deposited in the event channel.
Event Emitter (Agents)
Event emitters detect, gather, and transfer events. They also don’t know anything about event consumers, their existence, or how events are processed, which contributes to keeping components loosely coupled.
Event Notification
An event happens when a significant change in state occurs for any system hardware or software. The system then sends a message to tell other parts of the system that the event has happened. The event itself and the event notification are often mistakenly referred to interchangeably, which is incorrect. The event notification is a result of the event.
The event notification is configured in two parts. The event header provides a name for the event, a timestamp, and an indication of what type of event it is. The event body includes additional details about the event that will be useful further along. To maintain low coupling, the event notification does not anticipate any response.
From a DevOps perspective it’s worthwhile to note that while the event notification is relatively easy to set up, it can become difficult to trace in the event of program failure. The event notification flows through various systems, each of which is independent of others. With no fixed workflow to trace, debugging and modification can be challenging.
Event Handler
An event handler is a software routine that handles the occurrence of an event.
Event Loop
The event loop manages the interaction between events and event handlers.
Event Carried State Transfer
To reduce system latency, an event notification includes all details required to process the event. As it travels between systems, each maintains a copy of this data.
The latency reduction occurs when the system doesn’t need to make remote calls for information as it makes updates of its own copy. This also enables rapid reconstruction and reprocessing of an event. The hazard is that this will create different copies of the same data, which can lead to data inconsistency across the system.
Event Store
The event store is a database containing all stored events for future use when necessary. Events are published to an event stream or message broker, which allows subscribing consumers to access and process them as needed.
Event Sourcing
Event sourcing stores every change in state as an event in the event store, which adds significant resilience as any event can be rebuilt at any time in the future. This has the effect of making the event store the principal source of truth. Event sourcing also adds strong audit capability but cannot be depended upon as a sole solution as dependence upon other systems may make rebuilding difficult.
Event Queues
The flow of every event begins when a client sends an event to an event queue. This is, in turn, transports each event to the event mediator.
Event Mediator
When an event requires multiple steps, some level of orchestration is required to send additional asynchronous events to various event channels. The event mediator provides that orchestration.
Event Channels
An event channel is a messaging backbone that transports events in a standard format between event generators, event processors, and downstream subscribers.
Event Processors
Actions taken by event processing are based upon an evaluation of each event against established processing rules. Possible actions include the invocation of a specific service, the launching of a business process, the publication of the event to subscribers, the generation of another event, or simple storage of the event.
Event Consumers (Subscribers)
Events may initiate a variety of activities downstream. Activities such as commencing a service or business process may be pushed by the event processing engine while subscribers may pull event publications as needed. Possible event consumers or subscribers include applications, data warehouses, automated agents, active business processes, dashboards, or humans. Event consumers may choose from a wide variety of responses to each event, not respond to a given event, or store that event for later processing.
Understanding EDA Is Just the Beginning
As you read through these various processes, layers, and components, you traced the flow of events through an event-driven architecture. As discussed, EDA enables systems to respond to events occurring in other systems through extremely loose coupling.
But this loose coupling also brings a concomitant challenge in that there is no single established workflow that can be traced in an effort to resolve system challenges. Troubleshooting will undergo a transformation, but that’s a natural follow-on to the profound development change embodied in EDA.
Event-Driven Architecture is just one of the methods our product development teams use to drive your success. Contact 3Pillar Global today to learn how we can do it for you.
