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]
