Data Modeling in an Event Centric World
summary
Argues that modeling events as the tuple-level truth with a stream per row and grouped into category “tables” yields richer history and deterministic caches; implements per-stream atomic increment ids to detect gaps, enable optimistic concurrency and avoid distributed consensus; claims a practical cutoff: more than five degrees of freedom becomes unmaintainable so pipelines simplify systems; describes using Event Store plus Kafka/Kinesis/Azure Service Bus for public feeds; reports the approach working in production for auditability, scaling, and simpler cache invalidation.
AI-written summary · about
chapters (20)
- 0:00Introduction
- 1:47Speaker intro
- 2:30Event-driven systems simplify complexity
- 6:19Storage types in event systems
- 8:45Event sourcing vs state snapshots
- 10:55Business events as schemas
- 13:22Fine-grained streams and isolation
- 16:33Relational model primer
- 19:45Tables to event categories
- 22:13Event modeling for invoices
- 26:04Read models and sparse stores
- 28:57Atomic increments and consistency
- 33:14Linearizable updates and cash invalidation
- 36:50Multi-level atomic ordering
- 37:54Private vs public schemas
- 40:00Process history over state
- 41:23Q&A: Tables to events
- 42:05Q&A: Justifying event systems
- 42:46Q&A: Aggregate roots
- 44:09Closing
related talks
39mModern Event-driven Architecture: Adopting Data in Motion
40mThe Changing Face Of ETL: Event-driven Architectures for Data Engineers
52mEvent Sourcing for the Cloud Developer
51mThings I Wish I knew Before I Started with Event Sourcing
44mPolyglot Data
48mEvent Sourcing - what could possibly go wrong?
43mBack to fundamentals: from databases to event-driven platforms
17mOvercome By Events - Apache Kafka And Event-oriented Architecture