What is Event Sourcing
Event sourcing is a practice of keeping record of every change during the lifecycle of an application. In traditional approaches, usually the current state of the application is preserved. But the information of how we reached that state over time is lost. We lose information while updating data models.
Event sourcing ensures that all changes are captured in the forms of event object and stores them sequentially. Events are stored in append only mode and they are never to be modified.
Event sourcing is not a new concept. There are real world examples of practicing event sourcing:
An accountant keeps track of all transactions. He never erases or modifies previous records. He always creates a new entry, even to fix the previous mistake.
A doctor keeps record of patient’s medical history by adding new entry at the end of the journal
Why Event Sourcing is beneficial in financial application
Never lose information
No risk of losing important business information, as it store every changes in application state as event. It’s the biggest advantage of event sourcing based application. It is vitally important to keep track of every bit of financial data. And storing information is not that costly nowadays. We might never know in advance, which information will be useful in future.
Auditing is simple
Auditing is a vital part of any financial system. As all immutable events are appended sequentially in the event store, it is a readily available audit log of all past changes in the system or financial data
Event replay and Temporal queries
Travelling to a past state of a application is possible. Starting with initial application state and replaying all the events to a particular time, we can determine application state at any point of time. Also in case of failure, reconstruction of application state is possible by replaying the events.
By replaying, rewinding or stopping the actual events in a test environment, it’s possible to reproduce what went wrong in a certain situation. This form of debuggability is useful before deployment in production.
Event sourcing is often coupled with CQRS, an approach to separate read or query functionality from the write or command functionality. As reads and writes separated, each can be scalable with different magnitude with their separate optimization.
As events are never modified and added in the event store on append-only mode, data tampering will be hard and traceable. We can take the advantage of using WORM storage (Write Once Read Many), for storing events to ensure better security.
Domain Driven Design
Unlike CRUD operations, events are more relatable with business domain. Thus application architecture can be designed in a more Domain Driven approach. It is less likely to get carried away with technicality from the business domain
Keeping all business information allows us to estimate how things co-relate over time. This data allows us to draw various conclusions from past data, project estimates, analize customer behaviour etc.