It was 1494. Luca Pacioli - a Franciscan Monk, mathematician, and friend of Leonardo De Vinci - published a book he’d spent decades working on. Titled Summa de arithmetica, it would be the book that would see him gain his title: “the Father of accounting”.
Pacioli’s book contained the first published detailed description of the double-entry accounting system: a method of bookkeeping that relies on a two-sided accounting entry, known as a debit and credit.
This meant that should any changes occur in the log, the bookkeeper would add new entries into the book rather than overwrite previous entries. As such, the bookkeeper had visibility of any changes, when they occurred and by whom.
Event Sourcing is a pattern for storing data as events - a fact that took place in your business - in an append-only log. This means that, similarly to Pacioli’s double-entry method, original entries are retained rather than overwritten, keeping the context of any events.
The database you use for Event Sourcing matters. Consider that it was a good 500 years ago that Pacioli realised the importance of permanently storing changes made to logs. So you might be surprised to learn that today in our data-rich world, businesses are streaming their data into traditional databases that subsequently lose data and its context.
Traditional databases can be fantastic, there’s no denying that. Relational databases, for example, have been around since the 1970’s. There’s been a huge amount of effort and research put into them and we now have incredible distributed relational databases. But these have problems when it comes to Event Sourcing.
As your data becomes richer over time, these issues will be amplified.
To address the downfalls of traditional databases when it comes to Event Sourcing, a new category of operational database has emerged: the state-transition database.
State-transition databases are natively focused on storing events as an immutable sequence, keeping the order and business context of any state changes. Whilst events in the log cannot be changed, their effects can be altered by later events.
To demonstrate how this works in practice, imagine an “InvoiceIssued” event is appended to the log one day, only the address the invoice was issued to was incorrect. In your traditional database, the old address would likely be overwritten. But in your state-transition database:
For each event, the dates and times will also be stored. You can even store who made any changes to your data (e.g. customer or agent), allowing you to go back in time to understand what occurred. You’ll therefore retain the business context - information that’s usually lost in traditional databases.
The advantages of this model to your business are huge and span far beyond obvious benefits like having an audit-level amount of information for every event in your system.
EventStoreDB is an open-source event based state transition database that will allow you to keep the story behind your data. With use cases in almost every industry and big names like Walmart and Xero already using the database, find out how you can also harness the true power of event-driven architecture here.
This blog is also available as a webinar, where you'll learn more about applicable use cases. Watch on demand.