Event Sourcing
A pattern that persists the state of an entity as a sequence of immutable events rather than storing only the current state.
Also known as: ES, Event Store Pattern
Category: Software Development
Tags: architecture, software-design, patterns, domain-driven-design, event-driven
Explanation
Event Sourcing is an architectural pattern where the state of an application is determined by a sequence of events rather than by storing the current state directly. Instead of updating a row in a database, every state change is captured as an immutable event appended to an event store. The current state is reconstructed by replaying all events from the beginning (or from a snapshot).
**How it works:**
1. A command triggers a domain operation (e.g., 'Place Order')
2. The aggregate validates the command against current state
3. If valid, one or more domain events are produced ('OrderPlaced,' 'InventoryReserved')
4. Events are appended to the event store (append-only, immutable)
5. Current state is derived by replaying events
**Benefits:**
- **Complete audit trail**: Every change is recorded—you can answer 'what happened and when' for any point in time
- **Temporal queries**: Reconstruct the state at any historical point by replaying events up to that moment
- **Debugging**: Reproduce bugs by replaying the exact sequence of events that led to the issue
- **Event-driven integration**: Events naturally feed other systems, projections, and read models
- **No data loss**: Since events are never deleted or modified, no business information is lost
**Challenges:**
- **Event schema evolution**: As the domain model changes, older events may need migration or upcasting
- **Eventual consistency**: Read models are updated asynchronously, creating a delay between write and read
- **Complexity**: Significantly more complex than CRUD for simple domains
- **Storage growth**: Event stores grow indefinitely; snapshots help but add complexity
- **Learning curve**: Requires a fundamental shift in how developers think about persistence
**When to use:**
Event sourcing shines in domains with complex business logic, audit requirements, temporal queries, or event-driven architectures. It pairs naturally with CQRS (Command Query Responsibility Segregation), where the write model uses events and the read model uses optimized projections.
**When NOT to use:**
Simple CRUD applications, domains without audit requirements, or teams without experience in event-driven systems. The added complexity must be justified by genuine business needs.
Related Concepts
← Back to all concepts