The Data Side of Event Driven Architecture
summary
Event-driven systems must choose between full-payload vs key-based events: full payloads boost throughput at the cost of stamp coupling, contract versioning headaches, and huge bandwidth; key-based events simplify contracts and consistency but force synchronous DB lookups. Architectural quanta determine whether data is monolithic, domain-partitioned, or dedicated per service, each with trade-offs for availability and scale. Replication, explicit or implicit sync, or in-memory replication using hazelcast astgfire coherence and fitness mitigate sync needs but introduce their own limits (500 orders/sec → 250,000 KB/s).
AI-written summary · about
chapters (14)
- 0:00Introduction to EDA
- 1:52Event terminology in EDA
- 3:18The missing data in EDA
- 4:20Architectural quantum explained
- 7:32Data contract patterns
- 15:55Key-based vs data-based contracts
- 18:22Anemic events and granularity
- 26:10Data topologies in EDA
- 32:55Monolithic data topology
- 35:23Domain data topology
- 37:55Dedicated data topology
- 40:47Choosing the right topology
- 46:55Solutions for data dependency
- 53:14Summary and key takeaways
related talks
29mThe Design and Evolution of Event-Driven Databases
39mModern Event-driven Architecture: Adopting Data in Motion
57mEvent Driven Collaboration
48mEvent Sourcing - what could possibly go wrong?
32mTake back control of your data with Event Driven Systems
45mData Modeling in an Event Centric World
44mPolyglot Data
46mMicroservices Data Patterns: CQRS & Event Sourcing