The Power of Events: Embracing the Event-Driven Paradigm (Part 1)

Category:

Articles

Date:

February 17, 2025

In this blog post, we will discuss the Event concept in software engineering. This is the first part in our series dedicated to Event-Driven Architecture. We will learn the benefits of using events, examples of application of this paradigm, where it’s more suitable to build your systems’ architecture on events rather than traditional API-based approaches, and, most importantly, how to start thinking the event-driven way.

‍

The audience of this guide are software engineers involved in the software design process, or anyone who is interested in software architectures and already has some background in this area. Without further ado, let’s dive in)

‍

What exactly is an Event?

‍

An event is a significant occurrence or change in state that a system can detect and respond to. In other words, an event is something that has happened and requires our attention. Here are a few examples of such happenings:

‍

A button was clicked by a user;
A message has arrived in a queue;
A file was modified;
An order has been placed in an online store;

‍

Events originate from a specific source: user actions, system operations, external services, etc. They can carry data — we call this event payload, and, usually, they are handled asynchronously.

‍

Understanding of events comes best when comparing it with a more traditional concept called commands.

‍

Commands vs Events

‍

In traditional web development, we are dealing with commands. It’s also called an API-driven or Request / Response approach. It is simple, and its сause and effect relationships are easily taken by our brains.

‍

_{Here’s an example:}

We want to build an online chess game. After each game, each user’s rating is updated. Let’s think about how this can be implemented using commands vs events

‍

1. Commands are imperative, events are declarative

When we want to execute a command, we give specific instructions on what needs to be done: “updateUserRatingAfterGame”. When we want to send an event, we are just telling about what has happened: “gameFinished”. This is the responsibility of whoever is on the other side to decide whether or not you want to listen to this event and how you want to handle it.

‍

2. Events are immutable, commands are ephemeral

‍

‍

An event is an entity of itself. It can be stored and treated independently. It even may not be connected directly to the subscriber. Whereas a command is something that doesn’t really hang around. It exists only in the context of the connection between the two endpoints.

‍

3. Publisher — Subscriber behavior

‍

‍

The common logic behind the events is that there is one component of a system, called the Publisher or Producer, that’s responsible for raising an event. The other one is called the Subscriber or Consumer. It keeps the list of dependencies on one or more Publishers and reacts to any changes of state among those dependencies.

‍

It’s also called a Pub / Sub model. We will look into this in more detail in the second part of this series.

‍

4. Events usually require some sort of middleware

‍

‍

This is the important one. Usually, services are not connected to events directly. The piece of software that enables the transmission of events between different components of a system is called Event Broker. We’ll talk more about event brokers in the second part.

‍

5. One-to-One vs One-to-Many

‍

‍

Let’s get back to our chess game example. A “gameFinished” event sounds like it’s quite important, there is likely to be more than one service, that wants to subscribe to this event. “GameRoomService” wants to be notified to close the gaming room and clean up all the connections. “LeaderboardService” wants to get the data to update a leaderboard. It’s totally fine to propagate this event to more than one destination. Whereas a command or request-response model is limited to a “one source — one destination” type of communication.

‍

6. Naming differences

Many things can be said regarding differences in naming events vs naming commands. But apart from the obvious ones, like: the command should be Present Tense and the event should be Past Tense, there’s one that I find particularly interesting. If we take a look at the command, usually it is semantically closer to whom this command is addressed (“updateUserRatingAfterGame” — “UserRatingService”). Whereas in the case of events, it is closer to the source that raised this event (“GameService” — “gameFinished). Thus, as Martin Fowler said:

‍

Whether you use events or commands, under the cover they are basically the same thing. The difference is all about naming, but that difference is really important.

‍

Pros & Cons of using an Event-Driven approach

‍

Let’s guide you through the Pros & Cons of using EDA. To put it simply, this is not something that should be practiced everywhere. If you are developing a simple web application, doing basic CRUD operations, and handling an insignificant amount of data, it’s better to use a more traditional synchronous API-driven approach.

‍

Use-cases & examples

‍

Complex microservices communication

‍

Using EDA, independent services can communicate asynchronously without having a direct dependency on each other. This way you don’t have to think about other services, what are the endpoints, their signatures, authentication methods, etc. You are just raising an event about something happening in the system, and whoever is interested in this event, will get it asynchronously.

‍

There could be many examples of this topic:

‍

E-commerce system placing an order
The logistics app updates the parcel status
An online store sends notifications to users via multiple channels: e-mail, SMS, and push notifications.

‍

These are just a few of the possible examples.

‍

(Near) real-time data processing

‍

EDA systems are much better at handling high-frequency data operations. Because events are declarative and usually rely on some sort of middleware, you have much more flexibility in controlling and processing the event stream, rather than working with the hell load of synchronous requests.

‍

Examples of such systems:

‍

A trading app. Processes live stock market data to make trades and notify other positions.
IoT systems. The system’s back-end is bombarded by the amount of data sent from different sensors, that require to be analyzed and processed.
Gaming. Let’s consider the example that we used in this article, when one action or user input may trigger many different changes throughout the game.
We can also talk about things like banking, fraud-detection, ad tech, recommendation engines, healthcare systems, chatbots, etc.

‍

High availability and durability is crucial

‍

Sometimes you can not afford to lose a single piece of data even if some of your services are down and the rest of the system should remain operational. Event systems’ durability and recoverability can help with that.

‍

A good example of that is healthcare applications that are used to monitor patient’s vitals or send alerts in case of emergency.
A security monitor that tracks any unauthorized login attempts.

‍

Server-less or cloud-native applications

‍

Each time you think about dynamic scaling, it’s likely that the Event-Driven approach is preferable. EDA applications work really well with cloud-native solutions due to the fact they support auto-scaling in a nutshell.

‍

This could be AWS lambda or CI/CD pipelines.

‍

Preserving event history is important

‍

Because events are immutable it’s comfortable to use them in situations where you need to keep track of operations, because event stack is a history by itself. We’ll talk more about it in the next part when we’ll discuss some of the EDA patterns. For now, let’s say that those can be:

‍

Banking apps. For managing account ledgers.
Insurance systems. For easy access to the history of insurance cases of a particular person.
VCS for managing commits etc.

‍

Conclusion

‍

In this article we’ve learned what events really are, what are their benefits, and how all this plays together in a thing called the Event-Driven architecture. In the second part, we are going to talk about how to design and implement event-driven systems.