Why Event Sourced Systems Fail
summary
Common failures are concrete: 80–90% trace back to unfamiliarity and people, not the model. Hard technical problems are versioning across long-lived logs, solved by schema strategies or full release-time transforms that migrate events. Eventual consistency is often mitigable by returning a log position (for example Event Store returns an all‑position) and letting reads retry — a pattern implemented in a few minutes that removes most surprises. Benefits include many tailored read models and cheap geographic distribution; costs are operational experience and tooling.
AI-written summary · about
chapters (21)
- 0:00Intro
- 2:10Overview
- 4:00What is Event Sourcing
- 8:20Problems with Event Sourcing
- 12:10Arguments against Event Sourcing
- 12:30Versioning
- 13:35Weak Schema
- 14:12Transformation
- 16:58Modeling is different
- 19:47Diagrams
- 22:15cqrs
- 22:44transactional updates
- 23:26benefits of consistency
- 28:51geographic distribution
- 29:31consistency
- 32:57consistency issues
- 35:39real question
- 37:14questions
- 39:49QA
- 46:18Frameworks
- 48:01Outro
related talks
48mEvent Sourcing - what could possibly go wrong?
44mEvent Sourcing - You are doing it wrong
31mThe Power of Event-Driven Systems without Burning your Hands or Budgets
51mThings I Wish I knew Before I Started with Event Sourcing
52mEvent Sourcing: deep dive
54mThings I wish I knew before I started with event sourcing
52mEvent Sourcing for the Cloud Developer
46mEvent Sourcing: Superpower or super pain?