How to model event-sourced systems efficiently
summary
Event sourcing works but long per-entity streams cause IO, versioning and cognitive costs; teams slice by business life cycles (example: turn an account into account-month streams) rather than rely on snapshots that double writes and can break atomicity when stored in another stream. Practical tactics: truncate and archive closed cycles to blob storage or a secondary event-store, index archives in Elasticsearch for analytics, run scavenging in EventStoreDB. Example numbers: a personal estimate of 20,805 transactions versus observed longest stream of 160 million events.
AI-written summary · about
chapters (10)
- 0:00Introduction to event sourcing
- 2:16Basics of event sourcing with bank accounts
- 8:36Challenges with long event streams
- 11:29Problems with snapshots in event sourcing
- 19:58Modeling business life cycles in event streams
- 25:44Closing the books in event-sourced systems
- 34:31Archiving vs deleting event data
- 41:40Why snapshots are risky in production
- 45:11Practical advice for efficient event sourcing
- 49:12Key takeaways and conclusion
related talks
31mThe Power of Event-Driven Systems without Burning your Hands or Budgets
29mEVENT SOURCING IN AKKA PERSISTENCE
56mDeveloping Event-driven Microservices w/Event Sourcing and CQRS
52mHidden gems and traps that you probably didn't think of using Event Sourcing
56mAn Abridged Guide to Event Sourcing
51mImplementing an Event Sourcing strategy on Azure
35mEvent sourcing after page 1: How we built a cloud native bank
58mIntroduction to Event Sourcing