Use the Source, Luke: High-fidelity history with event-sourced data
summary
Event sourcing is used as the primary state store so application state is rebuilt by replaying serialized events, demonstrated with POROs as domain models and a simple Redis event store example that serializes events (JSON preferred) and snapshots to avoid replaying millions of records. A small library, replay gem, handles persisting events, applying them and notifying listeners; it proves useful for heavy analytics, auditability and bug fixes but trades increased design complexity and snapshotting for runtime performance.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 1:52Defining event sourcing
- 4:10Benefits of event sourcing
- 7:14Advanced use cases and benefits
- 12:07Drawbacks and trade-offs
- 15:54Common applications
- 18:03Code implementation example
- 24:26Introducing the Replay gem
- 28:23DCI architecture concepts
- 31:08CQRS explained
- 34:25Philosophy and best practices
- 37:26Q&A and concluding thoughts
related talks
43mEvent Sourcing dealing with an eventful past
39mEvent Sourcing with Elixir
51mThings I wish I knew before I started with event sourcing
01h 07mAn Architecture with CQRS and Event Sourcing
54mEvent Sourcing
52mEvent-driven vs event sourcing: what's really the difference?
48mEvent Sourcing - what could possibly go wrong?
49mCQRS and Event Sourcing explained