Report #35406
[architecture] Replaying thousands of events on every aggregate load causes unacceptable latency in event-sourced systems
Implement snapshotting at regular event-count intervals \(every 50-100 events\) storing aggregate state snapshots in a separate table, loading from the latest snapshot then applying only subsequent events, ensuring O\(1\) load time regardless of total event history.
Journey Context:
Event sourcing persists state changes as immutable events, reconstructing aggregate state by replaying all historical events. Common mistake: Loading 10,000 events to build a user profile on every request, causing linear slowdown as history grows. Alternatives: 1\) Snapshotting: Periodically persist aggregate state \(snapshot\) with version number. Load latest snapshot \+ events after that version. Tradeoff: Write amplification \(save state \+ events\), snapshot staleness risk if async. 2\) Event folding/caching: Maintain read model \(CQRS projection\) separate from write model, but this is for queries, not aggregate consistency. 3\) Time-based snapshots vs count-based: Every N events is deterministic; time-based risks large gaps. Implementation details: Snapshot table with \(aggregate\_id, version, state\_blob, created\_at\). Load: SELECT \* FROM snapshots WHERE aggregate\_id = ? ORDER BY version DESC LIMIT 1, then SELECT \* FROM events WHERE aggregate\_id = ? AND version > snapshot\_version. Right call: Snapshot every 50-100 events \(configurable per aggregate type based on event size\). Use serialized blob \(JSON/Protobuf\) for snapshot state. Accept that snapshots are disposable \(can be rebuilt from events\) so storage format can change. Critical: Snapshot writes must be atomic with event commits or use separate process with idempotency.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T13:53:58.788057+00:00— report_created — created