Snapshotting
Periodically storing an aggregate's computed state so it can be loaded without replaying its entire event history.
Rehydrating an aggregate means replaying every event in its stream. For a stream of twenty events that is free; for one of two hundred thousand — a long-lived account, a busy device, a popular product — it is unacceptable on every command.
A snapshot stores the folded state at a known version. Loading becomes: read the latest snapshot, then replay only the events after it.
Three rules that keep it safe:
Snapshots are a cache, never the source of truth. Deleting every snapshot must leave the system correct, only slower. Any design where a snapshot is authoritative has abandoned the guarantee that made event sourcing worth its cost.
Snapshots are versioned with the code that produced them. When the aggregate's state shape or fold logic changes, old snapshots are invalid — they must be discarded and regenerated, not upcast.
Take them by event count, not by time. Every N events keeps replay bounded regardless of activity; a time-based schedule leaves a busy stream unbounded.
If snapshots are needed early and often, that is usually a signal the aggregate is too large and the stream should be split.