Event Sourcing
summary
Event sourcing stores only facts and treats current state as a left fold over an append‑only event log, giving provable auditability and the ability to replay history to rebuild any read model. Practical claims: naive single‑node setups hit ~50–100k transactions/sec and tested persistence reaches ~700k/sec; systems usually don’t need concern until ~3–5k msgs/sec and most run under 10 TPS. Concrete fixes: using WORM storage stops super‑user tampering, consumer‑driven feeds like Kafka style avoid service‑bus control‑channel complexity, and replacing heavy SQL queries with purpose read models or Neo4j yields large speedups.
AI-written summary · about
chapters (24)
- 0:00Intro
- 1:00Event Sourcing
- 3:35Example
- 5:47State
- 9:27Append
- 11:12It depends
- 12:48Amazon example
- 16:45Alpha Beta
- 18:06Linearization
- 27:43Versioning Problems
- 28:08Introducing Event Sourcing
- 29:54Querying Events
- 30:44N Read Models
- 31:06Object Databases
- 35:56Accidental Complexity
- 37:58Service Buses
- 38:39Consumer vs Server Driven Subscriptions
- 41:54Complexity of Event Sourcing
- 42:56Big Companies Use Event Sourcing
- 43:29Slow Systems
- 44:26DomainDriven Design
- 45:13Best Framework
- 47:41CQRS
- 50:05Questions
related talks
48mEvent Sourcing - what could possibly go wrong?
43mEvent Sourcing dealing with an eventful past
51mThings I wish I knew before I started with event sourcing
52mEvent Sourced Transformation in Financial Systems
49mEvents... And what next?
39mEvent Sourcing with Elixir
52mEvent-driven vs event sourcing: what's really the difference?
01h 07mAn Architecture with CQRS and Event Sourcing