Event Sourcing dealing with an eventful past
summary
Claims that storing append-only streams with sequence numbers (not state) recovers history, removes DB locks, and shifts compute out of the database for easier distribution; demonstrates a shopping-cart example where losing intermediate adds/removes destroys recommendation signals. Shows practical mechanics: replay thousands of events in milliseconds, reconstruct aggregate by replay, append events, run projections into read models, and use snapshotting to avoid replaying millions of events. Recommends frameworks (Martin framework and EventStore/current and EventSourcingDB) and explains auditing needs and versioning strategies (backwards compatibility, upcasters).
AI-written summary Β· about
chapters (13)
- 0:00π Build Stuff Conference β Get Your Tickets!
- 0:28Introduction: Speaker Background & Context
- 2:15The Evolution of Databases & SQL Standards
- 5:40Trade-offs of Relational Databases: Integrity vs Performance
- 9:10Introducing Event Sourcing: A New Perspective on Data
- 12:30Commands, Events, and State Explained
- 16:05Real-World Example: Shopping Cart & Lost Business Data
- 19:40Event Streams vs State Storage
- 23:10How Event Sourcing Works in Practice (Lifecycle & Replay)
- 27:00Why We Store Events (Not Commands)
- 30:10CQRS, Projections & Read Models
- 33:20Advanced Concepts: Snapshots, Versioning & Scaling
- 36:10When to Use Event Sourcing & Final Takeaways
related talks
48mEvent Sourcing - what could possibly go wrong?
51mThings I wish I knew before I started with event sourcing
52mEvent-driven vs event sourcing: what's really the difference?
54mEvent Sourcing
01h 07mAn Architecture with CQRS and Event Sourcing
49mCQRS and Event Sourcing explained
39mEvent Sourcing with Elixir
52mUse the Source, Luke: High-fidelity history with event-sourced data