Play
Patterns

Event sourcing

Event sourcing stores every change as an event in an append-only log and builds current state by replaying it.

Event sourcing stores each change to an entity as an immutable event in an ordered log, and the current state is whatever you get by replaying those events.

Use it when the history matters as much as the present. An account balance is the sum of its deposits and withdrawals, so the log is an audit trail you cannot quietly edit. Martin Fowler lists what it buys: rebuild state from scratch, ask what the state was at any past time, and replay a corrected event with the ones after it. Chris Richardson adds a use that fits microservices, which is that publishing the events is the same write as saving them, so no separate message needs to be sent atomically.

It costs more than it looks. Replaying a long history is slow, so you keep periodic snapshots and replay only what came after. Events live forever, so changing their shape needs versioned schemas. Reading current state needs a read model built from the log, which is why it is usually paired with CQRS, and that read model is eventually consistent. Azure calls it a complex pattern that is costly to migrate to or from, so adopt it only when the history is worth that.

Nearest in Quorum#

The game has the log, not the pattern. The Event Stream keeps messages after they are read so consumers can replay them, and Research Event streaming unlocks it. Change data capture turns a database's write log into events, which gets some of the benefit without making events the source of truth. The Transactional outbox solves the write-and-publish problem in the usual way.

References#