What Is Event Sourcing?

Most systems store the present. A row in a table holds an account balance, an order status, a user’s current address — and every update overwrites what was there before. The value is correct, but the story is gone. You can see that the balance is $40; you cannot see that it was $100, then $10, then $40, or why.

Event sourcing makes the opposite choice. Instead of storing the current state, it stores the sequence of changes that produced it.

The mental model: the ledger, not the balance

The clearest analogy is an accountant’s ledger. A bank does not keep a single number for your balance and edit it on every transaction. It records each deposit and withdrawal as a permanent line item. Your balance is simply the sum of those lines — a value computed from history, never stored as the truth in its own right.

Event sourcing applies this discipline to software. The events are the source of truth. State is a projection.

Concretely, a shopping cart is not stored as { items: [A, B] }. It is stored as the facts that happened to it:

1
CartCreated          (id: 42)
2
ItemAdded            (sku: A)
3
ItemAdded            (sku: B)
4
ItemAdded            (sku: C)
5
ItemRemoved          (sku: C)

To answer “what is in cart 42 right now?”, you replay those events from the beginning and fold them into a current view: A and B. The events never change. The view is disposable and can always be rebuilt.

How it relates to event-driven architecture

Event sourcing is often confused with event-driven architecture, and the two are related but distinct.

Event-driven architecture is about communication between components: services announce facts, and other services react without being called directly. The events are messages in flight.

Event sourcing is about persistence within a component: the events are the durable record of everything that happened, and they are the database. The events are stored, not just transmitted.

They compose naturally. A service that is event-sourced already has a stream of facts describing its own history, so publishing those same facts to the outside world is nearly free. But you can do either one without the other — you can be event-driven with an ordinary database, and you can be event-sourced without ever publishing a message.

When to use it

Event sourcing earns its complexity in a specific set of situations:

• Audit and compliance are first-class requirements. When “who changed what, and when?” is a legal obligation, an append-only log of facts is not overhead — it is the feature.
• The history itself has value. Analytics, debugging, and machine learning often want the full path, not just the destination. Event sourcing keeps it by default.
• You need temporal queries. “What did this look like last Tuesday?” becomes a replay up to a point in time, rather than an impossible question.
• Business logic is genuinely event-shaped. Domains like accounting, trading, and logistics already think in terms of immutable transactions.
• It pairs with CQRS. Because reads are served from projections rather than the write model, you can build many specialized read views from the same event log.

When not to use it

The pattern is not a default, and applying it everywhere is a common and costly mistake.

Avoid it when the current state is all anyone will ever ask for, when the domain has no meaningful history, or when the team is not ready to operate the projections and schema evolution that the pattern demands. Simplicity that fits the problem beats sophistication that doesn’t.

Key takeaways

• Event sourcing stores an append-only log of facts and treats current state as a derived projection, not the source of truth.
• The mental model is a ledger: you record every change, and compute the balance by replaying it.
• It is distinct from event-driven architecture — persistence versus communication — though the two compose well.
• Reach for it when history, audit, or temporal queries have real value; avoid it for plain CRUD where only the present matters.

The question event sourcing answers is not “what is true now?” but “what happened, in order, to make it true?” When that second question matters, storing the answer is the whole point.