Event Sourcing - what could possibly go wrong?
summary
Based on 5 commercial projects, the talk gives concrete tradeoffs: event stores use relational DBs, Cassandra or Kafka with Avro/Protobuf; binary serialization yields 60–70% disk savings and schema evolution support; single-writer sharding and snapshotting solve concurrency and replay; mutable in-memory state raises throughput from ~17 to ~2200 ops/sec in one example; Cassandra advertises 100k TPS per cluster node as a scaling target; duplicates, split-brain and GDPR key-shredding are treated with practical solutions and known failure modes.
AI-written summary · about
chapters (21)
- 0:00Intro
- 0:11Software Mill
- 0:51What is Event Sourcing?
- 4:15Why Event Sourcing?
- 6:07ES and CQRS level 3.1.1
- 14:03ES and CQRS alternatives Change Capture Data CDC logging instead of event bus?
- 19:27library vs. framework
- 21:17Event store for Akka Persistence
- 22:07Cassandra perfect for ES? partitioning by design
- 23:25Event serialization
- 28:48Event payload
- 31:36State replay time
- 32:46Memory consumption
- 33:49Fixing state
- 35:11Handling duplicates
- 37:04Broken read model
- 38:27Multi aggregate transactional update
- 40:13Optimistic compensation action
- 43:00Cluster = split brain
- 44:31Cluster best practises
- 45:16Summary
related talks
52mEvent Sourcing for the Cloud Developer
44mEvent Sourcing - You are doing it wrong
51mThings I Wish I knew Before I Started with Event Sourcing
46mEvent Sourcing: Superpower or super pain?
24mHow To Combine Event Sourcing Architecture In Your Node.js Server
51mMicroservices Data Patterns: CQRS & Event Sourcing
36mThe Good, The Bad and The Ugly - An Event Sourcing Retrospective
39mEvent Sourcing made Simple