Walk through, step by step, how an event-sourced aggregate is reconstructed when a snapshot exists: what does the loading code fetch, in what order, and how does it combine the snapshot with the event stream?

## Reconstruction is a fold Reconstructing an event-sourced aggregate is, at its core, a **fold**: you start from some initial state and apply a sequence of events to it, each event transforming the state through the aggregate's own apply/when/on logic (whatever the framework calls the function that maps `(state, event) -> newState`). - **Without a snapshot**, that initial state is a blank aggregate — usually a default-constructed or 'empty' object of the aggregate's type — and the sequence is every event ever recorded for that aggregate's stream, fetched from version 1 (or 0, depending on numbering convention) onward. - **With a snapshot available**, the initial state changes: instead of starting from blank, you start from the state captured in the snapshot, and the event sequence shrinks to only the events recorded after the snapshot's version. ## The three-step algorithm Concretely, the algorithm has three steps. 1. **First**, the loading code asks the snapshot store — which may be a separate storage system, a special stream, or a table alongside the event store — for the most recent snapshot associated with the aggregate's identifier. That response includes the serialized state and, critically, the version or sequence number at which it was taken (e.g., 'this snapshot reflects the aggregate after event #4,820'). 2. **Second**, the code deserializes that payload into the aggregate's actual in-memory type, using whatever serialization format the system uses (JSON, Avro, protobuf, or a language-native format) — this deserialized object becomes the starting point of the fold instead of a blank aggregate. 3. **Third**, the code queries the event store for events belonging to that same aggregate's stream with a version strictly greater than the snapshot's version, fetched in ascending order, and applies each one in turn through the normal apply logic, exactly as if those events were arriving live. Once the last event in that tail has been applied, the aggregate object is now at the same version as the event store's head for that stream, and is ready to handle new commands or be inspected. If no snapshot exists yet — a brand-new aggregate, or a system where snapshotting was only just enabled — the first two steps are simply skipped, and the third step replays the entire stream from the beginning, which is the fallback path the whole mechanism exists to avoid needing routinely. ## Why the anchor is worth it The reason this exists is straightforward: the fold over the full event history is correct but its cost scales linearly with history length, and for long-lived, high-write aggregates that cost eventually violates whatever latency budget the read path has. Anchoring the fold's starting point at a recent snapshot converts an **O(total events)** operation into an **O(events-since-snapshot)** operation, which is the entire value proposition, and it costs nothing in correctness as long as the snapshot faithfully represents the state at its claimed version — which is the crux of most of the failure modes in this area. ## Hazard one — a snapshot that lies about its version The main correctness hazard in the restore path is a mismatch between what the snapshot claims (its version number) and what it actually contains. If a snapshot is tagged as version 4,820 but was actually captured after only 4,800 events were durably applied (a race between an async snapshot writer and concurrently-appended events, or a bug where the version counter is read before the state, or vice versa), then replaying events 4,821 onward on top of it silently produces wrong state — some events effectively get skipped or double counted relative to what they should be. This is worse than an unavailable snapshot, because an unavailable snapshot fails loudly (falls back to full replay) whereas a mistagged snapshot fails silently, producing plausible-looking but incorrect state. The standard defenses are: - derive the snapshot strictly from a durable read of the event store at a known version (never from 'whatever is currently in memory'); - and, defensively, verify on load that the event immediately after the snapshot's version actually exists and its version is exactly snapshot-version-plus-one — a gap there (e.g., due to stream truncation or a version-numbering bug) should trigger a fallback to full replay rather than blindly trusting the snapshot pointer. ## Hazard two — a shape change after a deploy A second common failure mode surfaces after a deploy: the aggregate's apply logic or field shape changes, and an old snapshot deserializes into a shape the new code doesn't expect (a missing field, a renamed field, a changed enum). Production systems typically tag each snapshot with a schema/aggregate-version number alongside the event-stream version, and on load, check that the snapshot's schema version matches what the current code expects; a mismatch causes the loader to discard the snapshot and fall back to full event replay, then optionally write a fresh, correctly-shaped snapshot afterward. **Akka Persistence's** snapshot recovery is a concrete, widely used implementation of exactly this restore algorithm: on actor restart, it loads the most recent snapshot (if any), then replays only the journal entries whose sequence number is greater than the snapshot's, applying each through the actor's `receiveRecover` handler before the actor becomes ready to process new commands.