Don't use Event Sourcing if you want auditability
May 05, 2020
The reasons for choosing an architecture can be so varied. We take into account customer needs, stakeholder requirements, legislation and non-functional requirements like availability and security.
At its core though, choosing an architecture is about choosing what you optimise for and the best choice, in the long run, is to optimise for change.
Event Sourcing is pretty popular right now and one reason I hear for choosing it is auditability, “if we have a log of all the events of changes in the system, we get auditability for free!”
I think this is a bad reason to choose Event Sourcing - you’re choosing a particularly difficult pattern, simply so you can check what the system has done in the past.
Why it might not provide auditability
It’s possible, and probable, you won’t get Event Sourcing right the first time, and who’s to say you actually have recorded all the events of the system? If you’re not testing your golden source of truth regularly then you may not have all your data in events and therefore your audit trail may not be complete.
Why you should really choose Event Sourcing
A good reason to choose Event Sourcing is that you don’t know your future requirements. No one can fully predict how a system will evolve or what will be needed a year from now. Having a stream of events of all the previous changes which can be read from any service allows you to be flexible and implement any future requirement - it’s truly extensible. This is because any requirement can be implemented as a new service and it can load in data, transforming it and enriching it to meet what’s needed. For example, a requirement to send email reminders to fill in some questions: a new service can now consume user events to get email addresses and names, along with the events about when they last filled in the questions. The new service builds up an understanding of the current state of the system and then uses that to make decisions. This is all possible without changing the existing services, which helps to reduce the chance of introducing regressions, and makes it simpler to deploy since the change is only adding services, not modifying any.
In this way, Event Sourcing optimises for dealing with change in requirements.
Written by Phil Hardwick