Why Event Sourcing Rebuilds State from an Event Sequence

Event Sequence: Storage Unit of Event Sourcing

Traditional CRUD stores only the current state (e.g., V1 → V2 → V3) and overwrites previous versions, so the system cannot answer "what was the state at a past moment". Event Sourcing stores every state‑changing event in order. Example: an account is created (E1), 100 is deposited (E2), 30 is withdrawn (E3); the current balance 70 is obtained by replaying E1 + E2 + E3.

Traditional CRUD overwrites the past; Event Sourcing preserves it.

Event streams must satisfy three indispensable constraints:

Immutability – once an event is written it cannot be modified or deleted; otherwise projections become untrustworthy.

Ordering – events for the same aggregate must be stored in the order they occurred, because the order determines the evolution of state.

Append‑only – the store only supports appends; there is no in‑place update, which guarantees immutability.

Key differences between CRUD and Event Sourcing:

Storage method: CRUD saves the current state; ES saves the event sequence.

Update method: CRUD overwrites old values; ES appends new events.

History retention: CRUD discards history; ES retains the complete history.

Audit trail: CRUD requires extra implementation; ES provides it natively.

Time travel: not supported by CRUD; supported by ES via replay.

Write performance: CRUD requires read + lock + overwrite; ES appends without reading.

Read complexity: CRUD reads directly; ES may need replay or snapshots.

Aggregate Rehydration: From Events to State

Rehydration (the "read" side of Event Sourcing) differs from a conventional database read. The process creates an empty aggregate and applies each event in order:

Create a zero‑balance account (E1).

Apply deposit of 100 (E2) → balance 100.

Apply withdrawal of 30 (E3) → balance 70.

The aggregate state is the result of this sequential computation, not a stored row.

Aggregate rehydration is a computation that derives state from the event sequence.

Because writes are pure appends, they avoid the read‑lock‑write cycle of CRUD. An Event Sourcing write consists of a single append; optimistic concurrency uses the event version to detect conflicts and retry if necessary.

Event Sourcing writes are faster than traditional CRUD – appends need no read, no lock, no conflict handling.

Snapshots: Performance Optimization for Long Event Streams

When an event stream grows, rehydration time increases. Snapshots mitigate this by periodically persisting the current aggregate state (commonly every 100 events). During rehydration the system loads the latest snapshot and replays only the events that occurred after it, keeping reconstruction time bounded regardless of total event count.

Snapshots are a pragmatic optimization – they truncate history only when it hurts performance.

Snapshots do not alter the core principle that the event sequence is the sole source of truth; even if a snapshot is lost, the full event log can rebuild the state.

Projections: From Events to Views

Projections are reusable read models built from the same event stream. Examples:

Current account balance (the "current state" view).

Monthly income‑expense report.

Audit log.

All these views are derived by applying different projection logic to the identical events. Projections naturally complement CQRS because the events produced by ES feed read models, but they also work without separating read and write models; they simply introduce eventual consistency, where a view may lag briefly before becoming consistent.

Projections let a single event stream serve countless different views.

Event Sourcing vs. CQRS: Orthogonal Relationship

Event Sourcing answers "how to store state" – it stores events, not the current snapshot. CQRS answers "how to separate reads and writes" – it uses distinct models for commands and queries. The two concerns are independent; they can be combined, but ES does not require CQRS.

Event Sourcing and DDD: Domain Events as the Source

Domain‑Driven Design defines domain events (e.g., OrderCreated, PaymentCompleted) that describe what happened in the domain. These events map directly to Event Sourcing events, making DDD a natural source for ES. DDD aggregates define transactional boundaries, which align exactly with ES aggregate rehydration units.

Domain events are the source of ES events; aggregates are the shared concept between DDD and ES.

Four Common Misunderstandings

Misconception 1: "Event Sourcing is just a log" – Logs are for human consumption and can be discarded; ES events are the authoritative source of state and must never be lost (Fowler 2005; community consensus).

Misconception 2: "Event Sourcing must be paired with CQRS" – The two are orthogonal; ES can be used with a single model, though pairing is common because events fit read models well (Young 2010; Fowler 2011).

Misconception 3: "Event Sourcing is a message queue" – Message queues handle inter‑process communication and may delete messages after consumption; ES persists events permanently for state reconstruction (community consensus).

Misconception 4: "Event Sourcing makes systems slower" – Reads may require replay, but snapshots keep read latency low, and writes are typically faster because they are simple appends without locks (Vernon 2013).

Logs can be lost; ES events cannot – logs are evidence, events are the essence.

In summary, Event Sourcing preserves the full history of changes, enables time‑travel, provides built‑in audit trails, and offers write‑performance benefits. It incurs storage growth, reconstruction complexity, and eventual‑consistency trade‑offs. Use it when history, auditability, or multiple projections are required; avoid it for simple CRUD‑only scenarios.