Event Sourcing: Superpower or super pain?
summary
Event sourcing records every change to insurance policies as an append‑only event log stored in MySQL (optionally CSV/parquet or Kafka for scale), with projections and snapshots to serve current views. Concrete wins: time travel to replay policy state, bi‑temporal events for future effective dates, pricing “what if” analysis against historical data, and richer cancellation context. Concrete pains: event versioning and code bloat, many projections diverging, slower eventual consistency (cards needed <100ms so required a hybrid), and dangerous partial events.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 3:07What is event sourcing
- 7:59Key terms in event sourcing
- 12:13Insurance claims flow
- 16:45Time travel with event sourcing
- 21:40X-ray vision into system state
- 25:07Shape-shifting schemas
- 28:16System bloat and complexity
- 31:45Speed and eventual consistency
- 34:18Learning curve and addiction
- 35:42Best practices
- 42:44Q&A
related talks
48mEvent Sourcing - what could possibly go wrong?
54mThings I wish I knew before I started with event sourcing
10mEvent sourcing
52mEvent Sourcing for the Cloud Developer
44mEvent Sourcing - You are doing it wrong
52mEvent Sourcing – the what, why & how
39mEvent Sourcing made Simple
36mThe Good, The Bad and The Ugly - An Event Sourcing Retrospective