Event Sourcing
Summary: An application architecture where all changes to application state are stored as an immutable sequence of events, rather than just the current state.
Sources: chapter11
Last updated: 2026-04-18
Core Idea
In event sourcing, the application log is the “source of truth.” Instead of updating a record in a database, the application appends an event (e.g., “Student enrolled in course”). The current state is derived by replaying the events from the beginning of time.
Advantages
- Auditability: Provides a complete history of how the current state was reached.
- Debugging: Allows replaying the event log to reproduce bugs or recover from an incorrect state.
- Flexibility: You can derive multiple different views (e.g., a search index and a relational table) from the same underlying event log.
- Immutability: Prevents destructive updates, making it easier to recover from accidental deletions.
Comparison with CDC
- CDC: Extracts changes from a database that is used in a mutable way. The application is often unaware that CDC is happening.
- Event Sourcing: The application is explicitly designed around events. Events represent user actions at a higher level of abstraction (e.g., “Item added to cart”) rather than low-level row updates.
Challenges
- Snapshots: Replaying millions of events to get the current state is slow, so periodic snapshots are required.
- Complexity: Requires a shift in mindset and can be more complex to implement than a traditional CRUD application.
Role in Unbundling Databases
Event sourcing is a fundamental building block for the “unbundling the database” approach. By treating the event log as the primary source of truth, an organization can derive any number of specialized datasets (materialized views, search indexes, analytics cubes) through deterministic functions. This architecture allows for a “database-inside-out” design where dataflow is explicit and components are loosely coupled (source: chapter12).