The Path to Event-Driven Mastery
The concept of “event” can be found in a wide range of different software domains. After writing my last article, “Events are the Key to Master Data¹”, a few questions I received made me realize that some of those ideas get easily mixed up. We will have a quick overview of different concepts related to events and how they are similar or different from each other.
Events, Commands, and Messages
An important thing to know before talking about events is to understand the differences and similarities between events, commands, and messages in the realm of software engineering. It can be challenging to make a clear distinction between those concepts:
- A message is data exchanged between multiple services or systems as a way of communication.
- An event is data representing something that has happened.
- A command is data representing something that should happen.
Events and commands are messages. The real difference between them is their purpose. A command materializes a request to trigger an action, while an event represents the result of that request. For example, let’s imagine a user wants to open a bank account. The system would create a command called OpenBankAccount. Once the command has been handled, and the bank account has been successfully opened, the system would fire a corresponding event called BankAccountOpened.
Now, where things might get complicated, is that commands and messages can be seen as events. We can consider that commands are events that represent requests. In our previous example, we can read our command OpenBankAccount as an event OpenBankAccountRequested. In the same way, messages are events representing communications.
It is essential to have a common language when we speak about events, commands, and messages. But the most important is to keep in mind that we are talking about data that help us understand the intent of our systems.
Event-Driven Programming
Event-driven programming² is a programming paradigm that you might be surprised to know you are presumably using daily. One of the most popular programming languages those days, JavaScript, is using a design pattern called the event loop. If I speak about onload or onclick you might realize that event-driven programming is a fundamental paradigm when it comes to building graphical user interfaces. Events are the perfect way to conceptualize user interactions. But JavaScript and its event loop are also heavily used on servers thanks to the popularity of Node.js. Event-driven programming is equally useful for dealing with sensors in IoT (Inter of things). When it comes to streams of events, I would highly recommend exploring a related paradigm: Functional Reactive Programming³.
Event-Driven Architecture
Event-driven architecture⁴ (EDA) is a software architecture paradigm. This architecture is trendy among microservices, but it can be equally useful in monoliths. The main idea behind EDA is to use events for asynchronous communication between services. Services will emit events that will be consumed by other services.
Domain-driven design⁵ (DDD) offers a lot of building blocks that can be very helpful in designing an EDA. It will help you break your application into domains and define the communication between them. I will give you a simple example: Imagine a domain is like a department in a company. Most companies have a marketing department and an accounting department. Both departments have customer data; however, this data is not the same for marketing or accounting. For marketing, customer data is used to increase sales. For accounting, it is just a record they add to their balance sheet. Both departments have separate customer data. But when the company gains a new customer, they both need to be aware of it. By emitting an event NewCostumerRegistered, both departments will be able to consume that event to update their customer records independently. They don’t care where that event came from; they just care about the event.
Event Sourcing
Event sourcing⁶ is a software architecture that stores the whole application state as a sequence of events. In contrast with EDA, it’s not only using events for communication, but they also have an even more central implication. Events represent the only single source of truth when it comes to data. They are the full history of the data.
CQRS⁷ is a pattern that is often used with Event Sourcing. Evaluating the entire sequence of events for every query can quickly become a performance issue. To avoid this, CQRS is used to keep snapshots of the application state. CQRS stands for Command Query Responsibility Segregation. The idea is to write the commands, in our case events, in one database and asynchronously update snapshots of the state with each incoming event in a separate database. The result will improve performance by allowing the system to query the database of snapshots directly instead of evaluating all events at each request.
Actor Model
The actor model⁸ is a conceptual model to deal with concurrent computation. It is built around the concept of “actor”. An actor is a unit of computation that receives messages and sends messages to other actors. The actor model is often combined with DDD to build reactive architectures. We mainly use this architecture to create message-driven applications, but it can be expanded to event-driven applications as well.
Erlang and Elixir are the most popular programming language with the actor model built-in. Akka is a Scala framework heavily used by Scala and Java developers to use the actor model on the JVM.
Redux
Redux⁹ is a design pattern and library. You might be surprised to find Redux on this list. However, this pattern has some strong similarities with an event-driven design. The idea of redux is that you have to emit actions that will be consumed by a reducer to update the application state. An action is a message that could be a command or an event, and the reducer is a simple message consumer. Similarly to event sourcing, the sequence of actions until a specific time represents the state of the application at that particular time. Redux is mainly used to build user interfaces in React, but we can use it to make any JavaScript applications, servers included.
Event Store
Event Store¹⁰ is an open-sourced event sourcing database. It was developed to build event-sourced systems and is probably the best and easiest solution to start an event-sourced project. You can use any kind of database to store your events, like MySQL or MongoDB. But depending on the technology you use, it might take more time to achieve a similar result.
Kafka¹¹ is an open-sourced stream-processing software platform that is very often used to build event-sourced systems. It’s not a database, but you can use it as a messaging and storage system. It is harder to use but offers some advantages: Kafka can be used for real-time streaming, to collect big data, and to do real-time analyses. It is famous for being fast, scalable, durable, and fault-tolerant. We use it in cases where other alternatives wouldn’t be able to handle the same volume and responsiveness.
Event Loop
The event loop¹² is a programming construct that watches and dispatches events or messages in a program. As said earlier, the most used programming language using this is JavaScript. But you can also find an event loop in Python inside the asyncio library. The way an event loop works is pretty straightforward:
- It makes a request to an event provider, for example, an event queue
- It waits until it receives a new event from the event provider
- It sends the received event to the corresponding event handler
For example, in JavaScript, you can add a callback function to the attribute onclick of a button. When the user clicks on that button, the event loop will call the callback function with the corresponding event as an argument.
Conclusion
There is much more to say about this subject, but this will give you an idea of different concepts you can explore. Events are particularly helpful in software engineering, and they open a wide range of possibilities to generate highly valuable data. In future articles, we will continue to explore how to improve data with events.
References
[1] Victor Nitu (2020). Events are the Key to Master Data https://medium.com/@nituvictor/events-are-the-key-to-master-data-11984332e435
[2] Wikipedia, the free encyclopedia (2020). Event-driven programming https://en.wikipedia.org/wiki/Event-driven_programming
[3] Dan Lew (2017). An Introduction to Functional Reactive Programming https://blog.danlew.net/2017/07/27/an-introduction-to-functional-reactive-programming/
[4] Wikipedia, the free encyclopedia (2020). Event-driven architecture https://en.wikipedia.org/wiki/Event-driven_architecture
[5] Eric Evans (2015). Domain-Driven Design Reference https://domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf
[6] Martin Fowler (2005). Event Sourcing https://martinfowler.com/eaaDev/EventSourcing.html
[7] Martin Fowler (2011). Command Query Responsibility Segregation https://martinfowler.com/bliki/CQRS.html
[8] Brian Storti (2015). The actor model in 10 minutes https://www.brianstorti.com/the-actor-model/
[9] Dan Abramov (2020). Motivation https://redux.js.org/introduction/motivation
[10] Event Store Limited (2020). Event Store — Event Sourcing Database https://eventstore.com/
[11] Apache Software Fondation (2017). Introduction https://kafka.apache.org/intro
[12] Wikipedia, the free encyclopedia (2019). Event loop https://en.wikipedia.org/wiki/Event_loop
