Event Sourcing
State vs Event sourced persistence
State-Oriented persistence system maintains only the current state
Event-Sourced persistence systems persist all state changes
Event sourcing suggests persisting the domain events in an Event store and using it for recreating the state of the domain objects at any point in time
Event store is an append only event log used for persisting the received events
Bank : Event Store example
- A transaction (command) emits a domain event
- Events are stored in an event store
- Streaming used for sourcing
Recreating the state from event data can lead to poor performance of queries (at runtime); to address it multiple materialized views are managed
- In case of bank account balance after every transaction is maintained in storage to achieve optimal performance
Why Event Sourcing?
- Event replay to create “point in time state”
- Multiple read models | views
- Accurate out of the box auditing
- Simplified Reconciliation
- Temporal & Complex historical queries
CQRS-Event Sourcing
- Commonly used together
- Events generated by commands are streamed to event store
- Read models used for optimal performance to serve query requests
