ruby_cool_kid.rb — Event-Driven Architecture. Part 1

Hello everyone! Long time no see. I have been pretty busy these past months and have not had a single minute to sit down and write something.

That is why I want to make it up to you. Let’s dive into Event-Driven Architecture .

What is Event-Driven Architecture?

This kind of design wants to reduce the load that the main system has by splitting an action into smaller tasks that can be executed one after the other, sequentially (if they need be), or async.

Additionally, these architectures help systems scale better with ease, and decoupling each of the tasks from the main system allows them also to fail independently rather than crash the whole runtime.

Furthermore, the architecture also allows a quicker development once the basics are in place. The event manager will be in charge of pushing the events to suitable listeners, getting rid of the need for heavy coordination between producers and consumers.

In a few words: Event-Driven Architecture design aims to decouple a system running actions outside of the main system in response to events.

The architecture is always formed by 3 players:

• Event Producer: The actor who produces the event in response to an action
• Event Bus/Event Broker/Event Manager: The part of the system in charge of routing the events to its suitable listeners
• Event Consumer/Event Listener: Part of the system that is in charge of executing a task based on a specific event.

The setup

Let’s see an example: John purchases a ticket for a concert.

Our backend will now receive the request from John to have the ticket. But if we go deeper, several tasks need to be done but let’s simplify to the extent.

First, check that the payment was successful. Then send the ticket to John.

At first, these tasks might not seem too heavy on the system, but let’s suppose we would need to check the successful payment on a third party and then generate the ticket pdf on runtime.

Adding up all the tasks can, not only take a lot of time, and the user kept waiting, but it also, can be confusing. If the ticket generation fails, it does not mean that the payment has, but the API will return an error code.

This example represents a bad UX that could be solved by just adjusting the architecture to use events.

This example is a simplified one and might not require a full-on development and implementation of a software architecture. But it is a clear and easy way of understanding the benefits of it.

Say it with events!

Backing up, John purchases a ticket, the payment goes through and it is reflected on his card. However, the feedback being shown to the user is that the transaction was unsuccessful due to an error in the ticket generation process. That can’t be right.

Applying what we saw in our last point, event-driven architecture aims to reduce the load on the system by executing different actions based on received events. If that is clear, let’s see it in action!

From our scenario, let’s think what are the points that the user is not that concerned about when purchasing the ticket.

In this case, it would be the generation of the ticket itself, as the user just needs to know that the payment was successful and the transaction went through, leaving us some room for the ticket generation.

Great! We have now detected our first modularization or encapsulation if you will, as we can encapsulate the whole ticket generation on an event.

As well, the whole ticket delivery generation can be encapsulated into an event for decoupling and resilience.

The system now looks more robust and we remove the bad UX experience that the user had in the past.

By showing the successful screen, and then executing the logic related to the ticket generation event, we ensure the user knows the transaction went through correctly and cover the case where the generation fails with another event. This event, representing the generation error could trigger another ticket generation attempt that, in the case it was correct, should trigger the event for delivering the ticket.

That’s all for today folks! We have covered the basics of event-driven architecture as well as a light example to wrap our heads around the concept.

Stay tuned for part 2 where we would be implementing this same example on a rails project.

Until then, keep coding!

Pavs.