Event Sourcing
In short
Event sourcing is a design pattern that stores every change to an application's state as an immutable event and rebuilds current state by replaying them.
What is event sourcing?
Event sourcing is an architectural pattern in which you store what happened, not just the end result. Instead of updating a row to hold the latest balance, the system appends events such as AccountOpened, MoneyDeposited, and MoneyWithdrawn to an append-only log called an event store. The current state is calculated by replaying those events in order.
Events are immutable: once written, they are never edited or deleted, so mistakes are fixed by adding a new correcting event. Because replaying thousands of events on every read would be slow, systems periodically save snapshots of the state and replay only the events that came after the latest snapshot. They also build read models, or projections, which are tables optimized for queries and kept up to date by listening to new events.
A bank statement is a good analogy: your balance is not a single number you must trust blindly, but the sum of every deposit and withdrawal listed on the statement. Event sourcing is popular in finance, accounting, order processing, and any domain that needs a full audit trail, the ability to answer 'what did this look like last Tuesday?', or the option to rebuild data in new shapes later.
Event sourcing is often confused with event-driven architecture. Event-driven architecture is about services communicating by publishing and reacting to events, while event sourcing is about using events as the storage model for a service's own data, and you can use either without the other. It is frequently paired with CQRS, which separates the write side that records events from the read side that serves queries. The trade-offs are real: event formats must evolve carefully, and read models are often eventually consistent, meaning they may briefly lag behind the latest events.
At a glance
Key takeaways
- State changes are stored as an append-only sequence of immutable events.
- Current state is rebuilt by replaying events, often starting from a snapshot.
- It provides a complete audit trail and makes it possible to reconstruct past states.
- It is often combined with CQRS, but it is not the same as event-driven architecture.
- Evolving event formats and eventually consistent read models add complexity.
Example
type AccountEvent = { type: "MoneyDeposited" | "MoneyWithdrawn"; amount: number };
// The event store only ever appends; past events are never changed
const events: AccountEvent[] = [
{ type: "MoneyDeposited", amount: 100 },
{ type: "MoneyWithdrawn", amount: 30 },
{ type: "MoneyDeposited", amount: 50 },
];
// Rebuild the current balance by replaying every event in order
const balance = events.reduce(
(total, e) => (e.type === "MoneyDeposited" ? total + e.amount : total - e.amount),
0,
);
console.log(balance); // 120Readers ask
What is the difference between event sourcing and event-driven architecture?
Event sourcing stores a service's own data as a log of events, while event-driven architecture uses events to let separate services communicate. A system can use one without the other, though they are often combined.
What is an event store?
An event store is a database or log designed to append events and read them back in order, usually grouped per entity, such as all events for one account. It can be a specialized database or an ordinary table used in an append-only way.
When should you not use event sourcing?
Avoid it for simple create, read, update, and delete applications where history has little business value. It adds complexity around event versioning, replays, and eventually consistent reads, which only pays off when auditability or questions about past states really matter.
See also
- CQRSSoftware Architecture, p. 10CQRS is an architectural pattern that separates the code that changes data, called commands, from the code that reads data, called queries, into two models.
- Event-Driven ArchitectureSoftware Architecture, p. 18Event-driven architecture is a software design style in which services communicate by producing and reacting to events, such as an order being placed.
- Domain-Driven DesignSoftware Architecture, p. 15Domain-driven design is an approach to building software that models the code closely on the business domain, using the same language as the domain experts.
- Message QueueBackend & APIs, p. 29A message queue is a component that stores messages from one service until another is ready to process them, so parts of a system can work asynchronously.
- DatabaseDatabases, p. 6A database is an organized collection of data stored on a computer, managed by software that lets applications save, search, and update it efficiently.
- MicroservicesSoftware Architecture, p. 27Microservices are an architectural style where an application is split into small, independently deployable services that communicate over a network.
Sources
Spotted a mistake or something missing on this page?Suggest an edit