During my career as a software engineer, event sourcing and event-driven architecture have popped up countless times on my radar, and I gained experience in both.

During talks with several colleagues and engineering enthusiasts, I tasted that there are still some unknowns of how these terms relate to each other, being seen as alternatives or competitors. In this story, we are going to debunk this! Let's begin by explaining first what both terms mean.

What is Event sourcing?

In our applications, the need for persisting information is inevitable. Even in the most straightforward setup, this consists of a database where data is getting saved. In the database, the current state of data gets stored.

But what if it is desired to track as well the complete series of actions taken of that data? The event sourcing pattern fills in this need. With event sourcing, data changes are getting saved in domain events. These events are held in the chronological order of occurrence. These events can be replayed to get to the current state of the data.

A real-world example of a default event-sourced system is a ledger like a bank account. The current balance of the account is the current state. To get to the current balance, several transactions are deducted or added to the start amount. These transactions are the events. When these transactions are replayed, you will get to the current balance.

What is Event-driven architecture?

Notifying other parts of your application about data updates within a monolithic system is easy. This process becomes much more complex in a distributed system. The services with this distributed system should be independent and loosely coupled to prevent a distributed monolith.

Unfortunately, there will always be some form of communication needed between different service boundaries. This is where event-driven architecture comes into play.

Event-driven architecture uses events to communicate notable data changes between service boundaries. Like the event sourcing pattern, the events represent a noteworthy change in state. Within event-driven architecture, the event is used as a data contract to communicate the information. The publisher and the consumer must have a common understanding of the message that gets shared. Otherwise, the message may be misinterpreted, and the information communicated will be incomplete.

A separate service is used to enable communication to prevent direct coupling between services. The most commonly used service is a message broker.

Why can't you compare these approaches?

As you may have already concluded, event-sourcing involves using events to persist the data changes. In contrast, event-driven architecture is about communicating events with data changes between service boundaries. This means that they solve different problems in a particular landscape.

Would it mean that they can be used together? Absolutely yes! Should event objects used in the event-sourcing implementation also be directly used for communication? No!

When solely depending on events used in the event-sourcing pattern, a direct dependency is created on the application's internal data. By creating a separate contract that represents the exact data change, a direct dependence on the same models is avoided, and internal data models are not leaked.

Summary

Although event sourcing and event-driven architecture both use events in their solutions, the use case is different. Both solutions can perfectly live next to each other but don't lay a direct dependency between both.

Useful References

Event Sourcing:

Event-driven Architecture:

Consider supporting my work by signing up to be a Medium member. It's $5 a month, and you get unlimited access to some of the best-written work on the internet.