.png){kind=small}
.png){kind=small}
An event is each and every action that provokes a systemic change of state. According to Gartner, by 2020, real-time and event-sourced situational awareness will be an essential feature for 80% of digital business solutions, and 80% of new business ecosystems will require support for event processing.
When we work with event-driven issues, what matters to us is an event that is significant to the activities of the organization, such as a customer’s request, the completion of a payment transaction, among others. We call such event a business event.
Event-Driven Architecture - or EDA, as it is known by closer friends - is an architectural standard that promotes production, detection, consumption and reaction to business events.
EDA is a way to accomplish communication between systems that consists mainly of asynchronous operations, in addition to allowing more scalable applications and generating less coupling between services, thus allowing a highly flexible architecture.
It is a model that does not depend on the size of its architecture, that is, it can be adapted to systems of any size. There are three important components of EDA:
Event generators are responsible for bringing about the event. It could be, for instance, a customer data platform, which, when the customer changes their address, is responsible for generating the event that will pass this action on to consumers. Event consumers are the event stakeholders.
Take, for example, a car insurance scenario. If a customer moves to a different address, the stakeholder is the quotation service, since a change in the customer’s location could affect the insurance rate.
The mediator or broker is responsible for receiving the event and passing it on to consumers. It’s important that you understand your own need well and combine it with one of the EDA topologies, mediator or broker, because establishing the intermediary of the event correctly is essential to successfully implement an EDA. Do you know when to use the mediator and when to use the broker? Let’s find it out together!
The mediator is used primarily when there is a need to perform manipulation or orchestration in event processing. In this topology, there are four types of main components: the queue, the mediator, the channels and the processors (all related to the events). The event stream starts when the client sends a message to the queue that is responsible for transporting the event to the mediator. The mediator receives the initial event and performs its orchestration by sending additional asynchronous events to the channels to perform each step of the process.
The processors, which listen in on the channels, receive the event from the mediator and perform a specific business logic to process it.
There are two types of event in this topology, the initial event and the processing event. We call initial event the original event that was received by the mediator, while processing events are those that are generated by the mediator and received by the processors. It’s necessary to be aware that the event mediator doesn’t perform any business logic, it only knows the steps that are required to process the event.
And it’s important to keep in mind that, independent of its granularity, the event processor should be responsible for executing a single business task, and it can’t rely on other processors to complete its task.
Imagine the scenario we mentioned before, of an insurance company – when the customer changes their address, it’s necessary to recalculate the insurance premium, because they may have changed to a more dangerous place, or even a quieter one, which directly influences the rates paid by the policyholder. In this case, we can implement a solution with EDA, as shown in the figure below:
In this example, there is the customer service, which is responsible for changing the data and triggering the address-change event into the queue, after which the customer service follows its normal flow. The event mediator can be notified that an event has arrived, or even check the queue for new information, it all depends on how you decide to implement it. The mediator, which knows the stream that the event should follow, will notify the quotation service first, which in turn will recalculate the insurance premium rate and return the processing event to the mediator.
The mediator will check whether a change in quotation has occurred and, if it has, the notification service is the next in line to receive the event and it will be responsible for notifying the customer regarding the change in the insurance rate. If the value has not been changed, the event stream ends right there. The mediator can be implemented, for example, with Apache Camel or Spring Integration.
When we have a simple event stream, in which we don’t need to perform event orchestration, we use the broker topology, which doesn’t have a central event mediator. It can be centralized and counts with the channels that are used in the stream, which can follow the queue model or message topics, or even a combination of them both. The main components of the broker topology are the broker and the processors.
Brokers support multi-channel communication, and each channel receives an identifier, and sending only one type of message to this channel is recommended as good practice. Now, thinking about the same example we mentioned above, let’s see how things work if we implement the broker topology:
Just as with the mediator, the customer service will post the address-change event in the queue, but in this scenario, we don’t have the mediator to orchestrate the event. The quotation service will receive the event through the queue, which can be done via a pull or push strategy, and it will perform the processing.
If the premium rate has been changed, the quotation service will post another event in the notification queue, which will indicate that the notification service must send the notification X to the customer Y. If the insurance rate hasn’t changed, the quotation service will terminate the processing without triggering any events. For this solution, we can use ActiveMQ, Google’s Pub/Sub, for example.
According to W. Roy Schulte’s book Event Processing, there are three main scenarios: information dissemination, which is when we keep in mind the need to maintain data consistency between the different applications and the main event doesn’t need to go through data changes before getting to the processors; situation awareness, when we usually have to analyse events from different sources to generate a new notification for one or more processors; and application integration, in which we should consider the approaches that will generate minimum coupling between the applications that will be involved in the integration. Each scenario will require a different form of architecture implementation.
All right, Ana. You’ve been on and on and on about it, but what should I do now?
First, you must understand your needs; it’s not because this subject has been hyped up that you should change your entire architecture to implement it. So, you have analysed things and spotted a gap? Let's choose the best architecture for it then.
A synchronous solution might solve your problem. We have checked and realize that EDA matches the problem perfectly? Let's choose the pattern that will best suit your scenario.
Stay tuned on our blog, because we will soon (really!) have a piece about it.
And finally, hands on! It’s necessary to run proofs of concept and implement the solution itself.
And you know what the best thing is? You don’t have to do this on your own! Get in touch with us, we have a team of experts ready to help you.
