Things I wish I knew before I started with event sourcing
summary
Event sourcing works as a local state-management pattern where events are the only source of truth, giving audit trails, time travel and business analytics but demanding versioning, snapshots and careful boundaries. Practical rules: prefer protobuf for versioning, keep private domain events and publish separate integration events, avoid replaying millions of events by using snapshots (e.g. snapshot every thousand events or on key business milestones) and enforce a single-writer principle via Akka sharding or Kafka partitioning.
AI-written summary · about
chapters (16)
- 0:00Introduction
- 1:10Event sourcing basics
- 6:22Event sourcing vs CRUD
- 8:49Benefits and trade-offs
- 15:52When to avoid event sourcing
- 16:13Domain modeling importance
- 19:43Eventual consistency
- 23:30Local approach to systems
- 26:20Event versioning strategies
- 30:12Refactoring event streams
- 31:59Frameworks and tools
- 36:13Long event streams risks
- 39:24Snapshot strategies
- 43:20Side effects handling
- 47:18Read models and projections
- 50:05Summary and advice
related talks
44mEvent Sourcing - You are doing it wrong
52mEvent Sourcing for the Cloud Developer
48mEvent Sourcing - what could possibly go wrong?
46mEvent Sourcing: Superpower or super pain?
52mEvent Sourcing: deep dive
52mEvent Sourcing – the what, why & how
36mThe Good, The Bad and The Ugly - An Event Sourcing Retrospective
31mThe Power of Event-Driven Systems without Burning your Hands or Budgets