The replay cost problem
In event sourcing, current state comes from replaying every event for an entity. When a stream has thousands of events, loading it on every request gets slow. Snapshotting fixes this by saving the computed state at a point in time.
How snapshots work
- Periodically, after some number of events, store a snapshot of the entity state with the event version it covers.
- To load an entity, read the latest snapshot, then replay only the events that came after it.
- The snapshot is a cache derived from events, never the source of truth.
Getting it right
- Snapshots are optional and rebuildable, so a corrupt snapshot can be discarded and recomputed.
- Choose a frequency that balances read speed against storage and write overhead.
- When event schemas change, old snapshots may need versioning or invalidation.
Key idea
A snapshot stores derived state at a version so loading replays only newer events, cutting replay cost without becoming the source of truth.