Event Sourcing
Event Sourcing is an architectural approach where changes to a system are stored as a sequence of events.
Classification
- ComplexityMedium
- Impact areaTechnical
- Decision typeArchitectural
- Organizational maturityIntermediate
Technical context
Principles & goals
Use cases & scenarios
Compromises
- Mismanagement of events can lead to inconsistencies.
- Events can be difficult to debug.
- Excessive storage can lead to high costs.
- Define events clearly and precisely.
- Process events in the correct order.
- Regularly review the event architecture.
I/O & resources
- Events that change the state
- Event handlers for processing
- Persistent storage for events
- Updated states based on events
- History of events
- Audit logs for compliance
Description
Event Sourcing is an architectural approach that allows tracking the state of a system by storing events. Instead of directly storing the current state, all changes are recorded as events. This enables a complete history of changes and facilitates restoring states at a specific point in time.
✔Benefits
- Complete traceability of changes.
- Easier restoration of states.
- Better support for audits and compliance.
✖Limitations
- Complexity in managing events.
- Potential performance issues with large data volumes.
- Requires a shift in data architecture thinking.
Trade-offs
Metrics
- Number of Stored Events
The total number of events stored in the system.
- Average Recovery Time
The average time taken to restore a state from events.
- Event Processing Time
The time taken to process an event.
Examples & implementations
Bank Application
A banking application that stores all transactions as events to ensure a complete history of account movements.
E-Commerce Platform
An e-commerce platform that stores orders and payments as events to track order status.
Content Management System
A CMS that stores changes to content as events to make the history of changes traceable.
Implementation steps
Define the events to be stored.
Implement the event handlers.
Set up the persistent storage.
⚠️ Technical debt & bottlenecks
Technical debt
- Insufficient infrastructure for events.
- Lack of documentation for events.
- Missing tests for event handlers.
Known bottlenecks
Misuse examples
- Using events as temporary data.
- Not storing events correctly.
- Not using events for audits.
Typical traps
- Assuming that events are easy to manage.
- Believing that all events are equally important.
- Underestimating the complexity of event processing.
Required skills
Architectural drivers
Constraints
- • Events must be immutable.
- • Events must be processed in the correct order.
- • Technical infrastructure must be in place.