Avoiding mistakes with events, an event at a time
summary
Argues that event systems fail from specific choices: mixing ID types breaks correlation so use UIDs over ints and include domain-qualified names; large payloads explode costs—teams cap messages (recommendations like 128k event size limit or 640k) and avoid sending PII for GDPR; reliable delivery uses outbox/inbox patterns and process managers, not blind brokers; provenance needs timestamps, monotonic process counters and trace/correlation IDs; Postgres can serve as a message store at large scale (35M users example).
AI-written summary · about
chapters (26)
- 0:00Introduction and speaker intro
- 2:01What is this talk about
- 4:06Not making events at all
- 7:44Going all-in on events
- 9:12Event ID design mistakes
- 15:12Designing for delivery mechanism
- 17:42Immutability of events
- 19:49GDPR and personal data in events
- 21:55Multiple delivery brokers issues
- 22:38Serialization pitfalls
- 24:29Event versioning challenges
- 25:54Missing schema in events
- 27:40Event naming conventions
- 29:06OpenAPI for event documentation
- 30:09What to store in events
- 31:34Guarantees and event order
- 33:22Outbox pattern pitfalls
- 34:03Massive event sizes
- 36:11The problem with timestamps
- 39:24Event-driven systems scaling
- 41:52Eventual consistency trade-offs
- 43:37Tracing events in distributed systems
- 45:21Not all events are equal
- 47:05Dealing with poor-quality third-party events
- 48:07Pivotal events and domain significance
- 50:15CQRS and event sourcing overengineering
related talks
50mAvoiding mistakes with events
49mAvoiding mistakes with events, one at a time
49mData Modeling in an Event Centric World
30mHow Event Driven Architectures Go Wrong & How to Fix Them
51mThings I wish I knew before I started with event sourcing
19mHow to Fail Your Event-Driven System
48mEvent Sourcing - what could possibly go wrong?
48m9 Fallacies of Event driven Architectures