Event Sourcing Versus Event-Driven Architecture
Comparing apples with pears?
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…
