Event-driven Architectures (EDA)

Event Notifications

After some time seeing companies adopting (sometimes without real justification) microservice-based architectures, we see a growing interest in event-driven architectures.

In this and other posts, we will introduce some key concepts and recurring patterns for using events in software development. Let’s start with systems that implement event notifications.

Understanding the basics

Imagine a system where every time a component (module, microservice, etc.) completes an operation, a related activity must start on another component.

For example, consider an e-commerce system where, once a sale has been confirmed, it is necessary to trigger the process of picking and to ship a product.

A simple approach would be to have the first component actively trigger the second component (by calling a method, making a request to some specific endpoint, sending a “command” message, etc.).

In our example, we might consider that the sales system would “call” the shipping system with a request to an endpoint, or, in a monolithic scenario, by executing a method.

A more complex sophisticated solution, however, would be to have the first component “firing” a message notifying the occurrence of a business event through an event bus. Then all other components registered in the event bus to receive this type of message would be triggered.

Thus, in our example, we could have the sales system “sending” an event message with sales-related data that has just been made. In the meantime, the shipping system would be “listening” to this event ready to do its work.

This approach has the positive side effect of allowing other components to “listen” to the same event by allowing additional processing to run without having to change the parts that are already working in the system.

Why develop systems with event notification?

Distributed systems (including those based on microservices) are becoming increasingly common. In these systems, one of the most important architectural attributes is loose coupling.

From Wikipedia:

In software engineeringcoupling is the degree of interdependence between software modules; a measure of how closely connected two routines or modules are; the strength of the relationships between modules.

Coupling is usually contrasted with cohesionLow coupling often correlates with high cohesion, and vice versa. Low coupling is often a sign of a well-structured computer system and a good design, and when combined with high cohesion, supports the general goals of high readability and maintainability.

In practical terms, we want to develop, distribute and maintain systems by changing their parts without affecting the others. The communication strategy between components, employing event notification, helps to develop systems with louse coupling.

Back in 2002, I worked on developing a complex CAD solution. One of the goals of the project at the time was to develop an extremely composable system (we wanted to be able to install plugins on the system, enriching its features).

We decided that each time an operation was performed, an event would be triggered. This way, plugins could be notified whenever an event of a certain type was triggered and were then able to perform related processing in a decoupled manner.

Points of attention on systems using event notifications

Loose coupling is great. However, it has a price that can be very high.

When we allow components to start listening for events in our application, it is easy to lose the track of what will happen.

In the CAD system I described above, we began to suffer from components that performed heavy processing in response to events, and the application often lost in responsiveness.

Distributed systems, which use event notifications, make some types of common operations (such as transactions) difficult to implement and especially to monitor.

It is important to remember that it is possible to achieve a good level of low coupling, too, by simply implementing asynchronous message exchange approaches (such as sending commands from one component to another using some messaging mechanism).

Takeaways

Implementing communication using event notifications is a powerful strategy to create louse coupled applications. Anyway, it is mandatory to design some kind of monitoring strategy to keep tracking of what is going on whenever an event is triggered.

Do you have any experience implementing event notifications? Share your thoughts in the comments.

More posts in Event-driven Architectures (EDA) series

Leave a Reply

Your email address will not be published. Required fields are marked *