Event-based architectures

The fast-paced reality demands immediate decisions from companies. In this context, the concept of event-driven architectures (EDA) emerges. Unlike traditional service-oriented models, where a request was needed for a system to produce a response, this model detects any “event” that occurs and acts accordingly in real time.

What are the “events” that trigger the system’s reaction? By definition, an event is a change of state of some key business system. This, put into practice, can be any user interaction with an application or website, a customer transaction in a physical or online store, or even the change of state of an appliance detected by an IoT device and reported automatically.

Events and messages

The examples of “events” are practically infinite -a person visiting the corporate site, a user abandoning a shopping cart, a machine experiencing a malfunction, a fleet vehicle deviating from its expected route, a raw material reaching the out-of-stock threshold, a package delivered to its destination, a user requesting a password reset-, and depend on the activity and interests of each organization. 

Another detail: events are omnipresent in companies of any industry, of any type and of any size. They exist everywhere and occur continuously. They are unavoidable.

On the other hand, we must differentiate between “event” and “message”. The first is the event itself. The second is the notification that the event occurred. When the notification is sent, the system “understands” that a state change has occurred and evaluates the appropriate response and who should get it. The application that received the message can reply or wait until the change in status has occurred.

For example, upon the aforementioned password reset request (the event), the system is notified of what happened (the message) and the client will likely receive an email with instructions to follow (the response).

EDA Architecture: Asynchrony and speed

In the EDA architecture, two groups of players are identified: event producers and event consumers. The first are the ones that generate the events that will be notified to the second ones to activate the processing involved in the response.

One of the characteristics of this architecture is that the communication is asynchronous: the sender and the receiver do not need to wait for the response from the other party to continue with their task. This is fundamental from the point of view of user experience, as there are no delays or obstacles.

Another notable difference from previous architectures is that while data remains the key raw material, events become the priority. Service-oriented models focused on not “wasting” any data, this one on ensuring that no event goes unanswered.

An important cultural shift associated with EDA, is that the older an event gets, the less valuable it becomes. Therefore, it is important to ensure that events are responded to as they occur. However, EDA also uses a tracking log to identify what happened with each event, generate performance metrics and provide the tools to move forward on a continuous improvement strategy.

Changes happen at full speed. EDA architectures propose to identify them quickly in order to handle them with more agile, contextual, responsive and efficient applications.