This is event sourcing in a nutshell. For a more comprehensive explanation, please have a look here for example.
This is the right choice here because this gives us total control and transparency. When we want to know how much money a particular user had 2 months ago at 1:42 pm, we can just query the needed transactions and sum them up. We know everything with this approach. And this is required to be compliant. As a side note, accounting does the same thing but, of course, they don’t call it event sourcing :)
But event sourcing comes with more advantages, including:
Rebuild state: you can always just discard the app state completely and rebuild it. You have all info you need, all events that ever took place.
Event replay: if we want to adjust a past event, for example because it was incorrect, we can just do that and rebuild the app state.
Event replay again: if we have received events in the wrong sequence, which is a common problem with systems that communicate with asynchronous messaging, we can just replay them and get the correct state.
Alternatives to Event Sourcing
Event sourcing definitely solves the auditability/compliance problem. But there are alternatives:
1. Audit Log Pattern: Keep the current state tables but add comprehensive audit logs that track all changes. This is simpler to implement but doesn’t provide the same level of detail as event sourcing. You track what changed, but not necessarily the business intent behind the change.
2. Change Data Capture (CDC): Use database-level tools to capture all changes automatically. Tools like Debezium can stream database changes, but this is more technical and less business-focused than event sourcing.
... continue reading