Avoiding mistakes with events, one at a time
summary
Shows concrete mistakes and fixes: skipping events causes audit-table bloat and slow, long business methods; using predictable numeric IDs or nanoid risks enumeration while UUIDs give time-based correlation; delivery zealotry (Kafka vs DB) favors starting with the app database and adding Kafka later; apply the outbox pattern to avoid lost events, monitor the outbox table for growth, and design for idempotence because exactly-once delivery is impossible. Avoid Java default serialization, prefer JSON/protobuf/Avro with a schema and test versioned deserialization.
AI-written summary · about
chapters (15)
- 0:00Introduction and motivation
- 4:48What is an event
- 8:19Mistake zero missing events
- 15:00Event identification pitfalls
- 23:39Delivery mechanism zealotry
- 27:34Immutable events and GDPR
- 32:31Event ordering and compensation
- 32:54Serialization mistakes
- 36:08Schema and event naming
- 39:59Overweight event problems
- 41:25Exactly once delivery myth
- 43:09Outbox pattern explained
- 45:18Events and tracing complexity
- 46:21TL;DR and book recommendations
- 47:43Q&A session
related talks
55mAvoiding mistakes with events, one event at a time
50mAvoiding mistakes with events
53mAvoiding mistakes with events, an event at a time
47mTop 10 Event-Driven Architecture Pitfalls
19mHow to Fail Your Event-Driven System
30mHow Event Driven Architectures Go Wrong & How to Fix Them
51mThings I wish I knew before I started with event sourcing
49mSo You Want to Maintain a Reliable Event-Driven System