Event-Driven Architectural Pattern

Even though the concept of events is almost as old as the arts of programming itself, Event-driven architecture or event-based solutions emerged and evolved to solve issues that started to appear in recent software architectures such as SOA (Service-oriented architecture) & Microservices and essentially patterns that involve in distributed computing. One of the common problems is that with new types of platforms in business models, microservices and cloud technologies became unsuitable or insufficient to meet the needs of modern organizations. The famous request/response approach in building distributed software systems started to become less sexy recently. Because today’s stakeholders cannot stand delays and passivity of systems. We want to know about everything as it happens or immediately after it happens. We don’t want to miss any important event. This is not possible with the common approach which is based on the request/response model.

Let’s consider an example of healthcare software system that is responsible for remote patient monitoring, treatment progress observation, doctor appointments and maintenance of vaccination & periodic check schedules. The system is cloud-based, of course, and incorporates with Internet of Things devices for its functioning. There are many client applications to this system for patients, doctors, staff members and for external entities. If the architecture of the system is based on the command request response approach, there will be a lot of tedious work to do by users of the system. Because when something changes or when something is done, performing the next step is a matter of actively sending a request to the system. In this case, the software system is unaware and unable to tell if something has changed or done. For instance, if blood pressure of a patient raises the nurse or the patient herself needs to notify the system by clicking over something to inform interested parties. Furthermore, if we want to inform a person that she has an appointment or her child needs vaccination, nurses or staff members need to keep track of patients records and consistently check if the appointment is near then sends a request to the system which in turn will notify the patient. You can see how this could be very tedious.

Now, without saying much, I’ll let you imagine if the system is event based and everything is based on action/reaction instead of request/response. In this case, the system has a sort of intelligence and is aware of everything that happens. Even better, handling events could be automated and thus less human intervention is needed.

The main components in an event-driven system is the event itself. Event is a message that represents facts, and it’s created when a change of an observed value happens such as an action by user. This event is generated or captured by what is referred to as the Event Generator. Event generator could be a monitoring agent sensor, a middleware, and etc. Captured fact is called the Initial Event, and it’s usually a message for example an HTTP message or some other type. It contains two parts Event Header and Event Body. The header contains metadata about the event such as the timestamp, event type, and ID. The body contains the change of states that happened. An event is captured so that interested parties could react to what happened. System’s responsibility is to notify the interested parties that an event has occurred so that those concerned components could react to it.

Next component is an Event Queue. Event-driven system could have more than one central event queue as well as different types of queues. Event queue is a first-in first-out that receives initial events and keeps them in order as they are received. The implementation of this component is not specified by the architectural pattern. Event queue is commonly used to generate event log and to keep track of events. So, the event queue receives a particular event or a stream of events and then transfers them to the mediator or broker components for processing. There are another types of queues as well. Reply Event Queue is used to send reply back to the event collector if the event is repeated invalid. Read Event Queue collects and handle only read events. Lastly, Write Event Queue is a good way to filter queues and increase efficiency & performance.

Next, we have Event Channel which is another type of queue used in event-driven systems as a medium between mediators and event processors, and also between events and events processors in the broker topology. This component is responsible for filtering and pre-processing events before reaching interested parties.

Mediator is an integration hub component in an event-driven system. It receives events from the event queue and transfer it to the appropriate event processor if it is a one-step event. In another scenario, it deveins the initial event into multiple events, orchestrate them and sends individual events to their corresponding handlers. It’s important to know that the mediator component does not perform any business logic related to the event. It simply orchestrates the steps involved in the initial event.

As a substitution to the mediator, Broker component does not need central orchestration. In such simple systems, events flow through events processors using the message broker as a medium of communication between event processors. The broker component contains events channels that are used for the event flow.

Finally, Event Processor is the equivalent of micro-service or a service component in SOA system. It listens on event channels and after it receives processing events, it reacts to them performing the logic necessary to handle them. After an event processor is finished with an event, it publishes an event to the broker or eventual notifying the system that its work is done. As we said earlier, more than one event processor could be interested in a particular event. Event processors are highly autonomous and decoupled atomic components.

Advantages:

· Improved Performance

· Scalability

· Deployability

· Versatility

· Adaptability

· Evolutionary Architecture

· Real-time Analytics & Event Sourcing

Limitations:

· Upfront Investment

· Increased Complexity

· Very Limited Testing