Surviving Long Event History
summary
Media publishing systems keep a full event journal for decades, using Akka persistent actors and an outbox for outgoing notifications, storing events in SQL and S3 origins; oldest events date to 2011 and the codebase handles millions of events with playback intact. Events use Protobuf schemas (no polymorphic JSON), payloads stay small, and snapshots run on hot aggregates — typically a snapshot every 100 events — letting the system evolve across languages, transports and platform upgrades while still rebuilding state.
AI-written summary · about
chapters (12)
- 0:00Introduction and context
- 2:06Defining domain and longevity
- 4:45Event sourcing vs state-based
- 7:32Why long event streams matter
- 10:53Hybrid approaches and AI
- 18:21Event survival guide principles
- 24:24System architecture and events
- 27:11Separating domain and DTOs
- 29:34Event design strategies
- 34:45Handling large event payloads
- 40:20Serialization and migration
- 47:41Migration and closing thoughts
related talks
38mSurviving Long Event History
49mEvents... And what next?
43mEvent Sourcing dealing with an eventful past
48mEvent Sourcing - what could possibly go wrong?
52mEvent Sourcing and CQRS
55mExperience report on using Akka in production: pitfalls and rewards
54mEvent Sourcing
51mThings I wish I knew before I started with event sourcing