Things I wish I knew before I started with event sourcing
summary
Event sourcing gives an immutable event log that enables time travel reports, audits and rebuilding lost projections but forces you to handle versioning, long streams and tooling. Examples: missed logging for skipped AI-driven trades lost months of business data; using Postgres as the event store and the outbox pattern for Kafka is practical; keep replay tooling and snapshots (every ~100–1,000 events) to avoid replaying hundreds of thousands of events. Use proto buffers for safe schema evolution, emit compensating “healing” events instead of editing past events, and design idempotent projections because exactly-once delivery doesn’t exist.
AI-written summary · about
chapters (24)
- 0:00Intro
- 2:00Presentation plan
- 3:27Meet the coder
- 3:55New feature request
- 6:32How many skipped adjustments
- 7:29If only
- 8:08Skipped variant
- 9:34Instant Smart Trader
- 10:38New Teammate
- 11:19Metadata
- 11:46Even sourcing
- 12:20How it works
- 12:45The cloud
- 13:28The state
- 14:19Read site
- 18:13Benefits
- 21:30Complexity
- 23:56Event sourcing
- 26:52Domain Discovery
- 28:18Event Source System
- 35:05Feature Removal
- 38:17Requirements Change
- 43:25Even Source Approach
- 46:35Performance Scalability
related talks
48mEvent Sourcing - what could possibly go wrong?
43mEvent Sourcing dealing with an eventful past
54mEvent Sourcing
58mIntroduction to Event Sourcing
52mEvent-driven vs event sourcing: what's really the difference?
01h 07mAn Architecture with CQRS and Event Sourcing
49mEvents... And what next?
39mEvent Sourcing with Elixir