Data Modeling in an Event Centric World
summary
Argues that switching to an event‑centric model keeps traditional relational thinking but replaces hidden joins with an ordered persistence log and addressable streams per entity so each invoice or customer has its own stream (often ~30 events) and services consume sequential positions for simple idempotency and miss detection. Recommends naming events in past tense, storing causation and correlation IDs, keeping events sparse (no display data), using snapshots to avoid 12‑hour replays, segregating personal data for GDPR, and publishing via an anti‑corruption public vs private events layer.
AI-written summary · about
chapters (26)
- 0:00Introduction to event-centric data
- 2:16Problems with relational databases
- 4:06CQRS and event pipelines
- 5:50Ordered storage types
- 7:35Four data recording models
- 9:04Event sourcing fundamentals
- 11:55Database structure for events
- 14:10Building event-driven systems
- 16:18Relational vs event models
- 19:06Modeling business events
- 22:36Event naming and history
- 25:24Power of event naming
- 26:50Event sourcing storage efficiency
- 27:53Creating read models
- 30:21Querying multiple event streams
- 32:54Handling mistakes in events
- 34:48Causation and correlation IDs
- 36:14Monotonically increasing numbers
- 37:52Optimistic concurrency control
- 39:17Fine-grained event streams
- 40:00Public vs private event schemas
- 41:44Best practices for events
- 43:08Data retention policies
- 44:59Real-time event processing
- 47:05Transactional event storage
- 48:32Q&A and closing
related talks
56mEvents on the outside, on the inside and at the core
50mAvoiding mistakes with events
53mAvoiding mistakes with events, an event at a time
50mMoving away from CRUD: DDD + CQRS
44mThe Dark Side of Events
52mEvent-driven vs event sourcing: what's really the difference?
49mDemystifying ‘Event’ Related Software Concepts and Methodologies
43mEvent Sourcing dealing with an eventful past