Event Sourcing Concepts

An event store is an append-only database that records every state-changing event in the order it happened, serving as the system's source of truth. Instead of storing only the current state, you store the full history of facts, like OrderPlaced or ItemShipped. Current state is rebuilt by replaying those events. This preserves a complete audit trail, enables temporal queries, and supports rebuilding alternative views. Events are immutable once written, which is central to the integrity of the approach.

An aggregate is a cluster of related domain objects treated as a single unit, forming a consistency boundary. It receives commands, validates business rules against its current state, and emits events describing what changed. The aggregate's state is reconstructed by replaying its past events. Because all changes to an aggregate go through it, invariants stay enforced. Aggregates keep transactional scope small, since each command typically affects one aggregate, which aligns well with eventual consistency between aggregates.

A projection transforms the event stream into a read model optimized for queries. Because the event store is great for writes but awkward for arbitrary reads, projections subscribe to events and build denormalized views, such as a table of current order statuses. This is the read side of CQRS. Projections can be rebuilt at any time by replaying events, and you can maintain multiple projections of the same events tailored to different query needs, decoupling read shapes from the write model.

A snapshot captures an aggregate's computed state at a particular version so you do not have to replay its entire event history every time you load it. When rehydrating, you load the latest snapshot and then apply only the events that occurred after it, which keeps reconstruction fast for long-lived aggregates with many events. Snapshots are an optimization, not the source of truth; the events remain authoritative, and snapshots can be regenerated if needed.

Replay is the act of re-processing the stored events from the event store, in order, to reconstruct an aggregate's state or to rebuild a projection. Because events are the source of truth, you can replay them to create new read models, fix a corrupted projection, migrate to a new schema, or debug how a system reached a given state. This ability to deterministically reproduce state from history is one of event sourcing's most powerful properties.