Event Sourcing
Event Sourcing records the sequence of state-changing events rather than repeatedly overwriting a current-state row. The current state is reconstructed from that event history, and alternative read models can be built from the same stream.
βΆArchitecture Diagram
π Data FlowDashed line animations indicate the flow direction of data or requests
CRUD storage tells you the latest value but often hides how it got there. That makes auditability, replay, debugging, and alternate projections harder in domains where the sequence of change matters. Event Sourcing exists for cases where history is part of the business truth, not just an implementation detail.
As event streaming matured and audit-heavy domains demanded better history, append-only event logs became more attractive as a first-class system record. The appeal grew strongest where replay, temporal reasoning, and traceability mattered more than simple current-state storage.
Commands are validated by an aggregate, new events are appended to an event store, and projectors turn those events into read-friendly views. The write model focuses on producing valid state transitions, while the read side focuses on projection and query shape.
CQRS separates read and write models; Event Sourcing changes the persistence model of the write side itself. You can use CQRS without Event Sourcing. For straightforward CRUD domains, event versioning and replay concerns can be unnecessary overhead.
Event Sourcing is a strong fit for ledgers, workflow-heavy domains, contract state machines, and other systems where the history of change has business value. It is much less compelling when the latest state is all anyone needs and replay complexity brings little benefit.