How to Fail Your Event-Driven System
summary
Practical checklist for common failures: use a Kafka cluster with well designed partition keys to avoid hot partitions and preserve ordering, run a schema registry and version schemas with tests before rollout, enforce auth, ACLs and rate limits and maintain a topic catalog, implement dead letter queue handling and limited retries, use CDC or the outbox pattern to avoid lost publishes, generate idempotency/duplication keys for exactly once effects, and instrument messages with tracing metadata for replay and debugging.
AI-written summary · about
chapters (15)
- 0:00Failing event-driven systems
- 1:51Core components
- 3:57Events vs commands
- 5:46Synchronous habits break async
- 7:13Partitioning pitfalls
- 8:38Schema evolution
- 10:23Access control in topics
- 12:10Dead letter queues
- 13:34Duplicate messages
- 14:58Consistency challenges
- 15:39Outbox pattern
- 16:01Event ordering
- 16:43Replay strategies
- 17:49Observability
- 18:52Q&A
related talks
46mMake Your Kafka Applications More Robust
49mAvoiding mistakes with events, one at a time
50mAvoiding mistakes with events
40mPrincipals of System Integration
30mHow Event Driven Architectures Go Wrong & How to Fix Them
58mLet's build the worst Event Sourcing system!
53mAvoiding mistakes with events, an event at a time
48mEvent Sourcing - what could possibly go wrong?
