Member-only story
Event driven architectures vs event sourcing patterns
The other day, I was talking to a Database Administrator about database fault tolerance and the different types of Transaction Logs. For reference in this article, a transaction log (also transaction journal or database log) keeps a history of actions (events) executed by a database management system used to guarantee ACID properties over crashes or hardware failures.
Databases store events internally to guarantee ACID properties. Does it mean a Database system implements an event driven architecture? The Short answer is no. And this is why.
This goes back to one of the greatest thought-provoking presentations from Martin Fowler about Event Sourcing[4] to understand that Event-driven architecture patterns are not the same as event sourcing.
Event driven architectures
The term Event driven architecture is used for any kind of software system which is based on components communicating mainly or exclusively through events. This software architecture paradigm promotes the production, detection, consumption of, and reaction to events. An event can be defined as “a significant change in state”. In the context of EDAs, the term “event” usually means “notification”. [2]
Event sourcing
Event sourcing is a much more special term, referring to systems that store all changes to the application state as a sequence of events. A well-known popular class of examples are transactional database systems, which store any state changes in a transaction log. Here, the term “event” refers more to “state change”, not only to “notification”.
The state is persisted as a series of events in a place called the event store. New events get appended, but they don’t overwrite old events. As a result, all history is maintained.
Comparison
Let’s contrast them in several areas:
Purpose
Event sourcing is an alternative to traditional persistence strategies, with the purpose of keeping history. Event driven architecture is a distributed asynchronous architecture pattern used to produce highly scalable applications. In other words, event sourcing is about having historical records…
