In an event-sourced CQRS write model, before a command handler can validate and apply a new command against an aggregate (say, an existing Order), the aggregate's current in-memory state has to be produced somehow — there's no row to just SELECT. How does that reconstitution actually happen?

## What Event Sourcing takes away In a state-stored write model, loading an aggregate before handling a command is trivial: you run a `SELECT` against a row (or a small set of joined rows) keyed by aggregate ID, and you get current state directly. Event Sourcing removes that row entirely — there's nothing to `SELECT`, because the write model never stores 'current state' as a persisted structure at all. What's stored is only the ordered sequence of events that happened to that specific aggregate instance: `OrderPlaced`, `ItemAdded`, `ItemAdded`, `PaymentAuthorized`, `OrderShipped`, each tagged with the aggregate's stream identity (e.g., `order-8f21c`). **Reconstitution** is the process of turning that sequence back into a usable in-memory object right before a command needs it. ## The three steps Mechanically, it works in three steps. 1. First, the system reads every event belonging to that one aggregate's stream, in the exact order they were originally appended — ordering is essential here, since applying `OrderShipped` before `OrderPlaced` would produce nonsense. 2. Second, it creates a brand-new instance of the aggregate type in its default, empty state (an `Order` with no items, no status, existence not yet confirmed). 3. Third, it folds the events over that empty instance one at a time by calling an `apply(event)` method for each — a pure state-transition function that says, for example, 'when you see an ItemAdded event, push this item onto the items list' or 'when you see an OrderShipped event, set status to Shipped and record the timestamp.' This apply logic does no validation and can't fail or reject anything, because these events are historical fact — they already happened, by definition, or they wouldn't be in the log. After the last event has been folded in, the resulting object is functionally identical to what a `SELECT` would have returned in a state-stored system: the current state of that one aggregate, ready to be reasoned about. ## Then, and only then, the decision Only once that fold is complete does the command handler's actual business logic run — typically a `decide(command)` method on the now-populated aggregate that inspects current state (can this order still be cancelled? has it already shipped?), either rejects the command with a domain error or produces one or more new events representing what should happen next (`OrderCancelled`), which then get appended to the same stream, immediately after the events that were just replayed to build state. This **load-fold-decide-append** cycle is the single control loop every command goes through in an ES write model, and it's worth being explicit that the load and fold steps are pure mechanical replay with no business rules involved — all the actual domain logic lives in `decide`, evaluated against the freshly reconstituted state. ## Why the design is built this way The reason this design exists rather than just storing current state directly is that it's the same mechanism that makes the event log the **single source of truth**: state is never an independently-maintained, potentially-out-of-sync artifact — it's always a deterministic, reproducible function of the events, computed fresh (or from a cached snapshot) whenever it's needed. That guarantee is what makes the audit trail trustworthy and what makes rebuilding read-model projections from history possible at all. ## The cost, and how it is bounded The obvious cost is **replay volume**: a long-lived aggregate that has accumulated tens of thousands of events (a years-old customer account, a heavily-modified document) would, under pure replay, force every single command against it to re-fold that entire history from event #1, which gets slower the longer the aggregate lives and eventually becomes a real production bottleneck: - command latency creeping upward; - database read volume spiking on hot aggregates. The standard mitigation is periodic **snapshotting**: persist the folded state at, say, every 100th event, and on reconstitution, load the nearest snapshot plus only the events appended after it, rather than the full history. The exact snapshotting mechanism is usually treated as an internal detail of the event store, but the fact that unbounded replay is a real cost — and that some strategy is needed to bound it — is absolutely something an engineer designing the write side needs to reason about. ## Reconstitution in a banking ledger A concrete illustration: in a banking-ledger-style event-sourced account aggregate, reconstituting an account before processing a `Withdraw` command means replaying every `Deposited` and `Withdrawn` event for that account since it was opened, folding each into a running balance, and only once that balance is known does the Withdraw command's overdraft-check logic run against it — the check itself is meaningless without first having replayed history to know what the balance actually is.