Archivearchitecture
Event Sourcing: Where Teams Get Stuck
The log is easy. Schema evolution, snapshots, and replay semantics are the hard parts.
- Published
- Reading time
- 1 min read
Event sourcing stores every state change as an immutable event and derives current state by replay. It gives you an audit log, temporal queries, and the ability to rebuild projections — at a price.
The sticking points
- Schema evolution: events are immutable, but your understanding changes. You need versioned event types and upcasters that transform old events at read time. Deleting fields is forever.
- Snapshots: replay from zero becomes too slow. Snapshots are a cache with their own invalidation and versioning problems.
- Projections: read models are eventually consistent; rebuilding one is a batch job that competes with live traffic.
- GDPR and deletion: "immutable" conflicts with "delete my data". Crypto-shredding (per-subject keys) is the usual answer.
When it is worth it
Domains with real temporal semantics — ledgers, workflows, inventory — and teams prepared to own the tooling. For simple CRUD, the audit table is cheaper.
Takeaway: event sourcing moves complexity from writes to evolution and replay. Adopt it for the model, not for the buzzword.