Events! Events Everywhere!
summary
Claim: events are facts — once emitted they describe something that already happened and receivers failing to process them is their problem. Distinguishes event sourcing is internal persistence (store a sequence of changes inside a service, use projections for queries) from event streaming is an API (publish domain events to Kafka/Pulsar/etc. for cross-service collaboration). Warns against treating an enterprise Kafka topic as the global source of truth or emitting only notifications instead of event-carried state; commands require feedback, events do not.
AI-written summary · about
chapters (11)
- 0:00Intro
- 0:55Everybody Loves Events
- 6:01What's the problem with this?
- 10:51How Domain Events Usually Come About
- 11:33Temporal Decoupling
- 13:09Event Sourcing?
- 14:17Event Sourcing Inside
- 19:38Listen to your own events?
- 20:32Inside vs outside, persistence vs API
- 24:49And the other way around (Event Streaming and Event Collaboration without Event Sourcing)
- 33:37Commands and Queries
related talks
49mDemystifying ‘Event’ Related Software Concepts and Methodologies
54mDemystifying ‘Event’ Related Software Concepts and Methodologies
52mEvent Sourcing for the Cloud Developer
55mAn Introduction to Enterprise Design Events
52mEvent-driven vs event sourcing: what's really the difference?
44mEvent Sourcing - You are doing it wrong
46mEvent-Driven Microservices - not (just) about Events!
31mThe Power of Event-Driven Systems without Burning your Hands or Budgets