Avoiding mistakes with events, one event at a time
summary
Practical advice: store events in a regular database rather than reflexively choosing Kafka—Postgres as event store works for many systems—use UUIDs for verifiable IDs (NanoID for compact front-end tokens), enforce schemas (Protobuf or JSON Schema), implement outbox pattern with idempotency keys, set size limits (e.g. 128KB per event), monitor event-table growth and VACUUM activity, treat >10,000 pending events or oldest undelivered >1 hour as a red flag, and record multiple timestamps (receive/process/emit).
AI-written summary · about
chapters (20)
- 0:00Introduction and speaker intro
- 2:18What are events and common mistakes
- 15:56Event identifiers and correlation IDs
- 16:39Delivery mechanisms for events
- 19:11Immutability and event alteration
- 22:01Storage and retention of events
- 23:06Multiple communication channels
- 24:10Serialization pitfalls with events
- 26:41Event versioning and schema
- 32:21Event content design
- 34:51Guarantees and delivery patterns
- 37:16Massive events and size limits
- 38:42Timestamps and time handling
- 41:16Distributed system failures
- 43:23Tracing and circular dependencies
- 46:15Selecting important events
- 47:39Poor quality systems integration
- 49:05Overusing patterns and complexity
- 50:49Recommended reading
- 51:30Q&A session
related talks
49mAvoiding mistakes with events, one at a time
30mUnhappy Path & Dealing with Bad Events
31mDesigning a mission critical event system
48mEvent-Driven Architecture – Benefits and Pitfalls
49mSo You Want to Maintain a Reliable Event-Driven System
48mEvent Sourcing - what could possibly go wrong?
31mThe Power of Event-Driven Systems without Burning your Hands or Budgets
54mThings I wish I knew before I started with event sourcing