Unifying API and event driven architectures
summary
Argues for an API first, Event always pattern that designs with Domain Driven Design and event storming, and reports it succeeds on large systems with 40 deployments/day by auto-publishing change events from entities. Describes a one‑line Spring library called Spring Data Event (released one month ago) that forwards post‑persist/post‑update/post‑delete to Kafka, recommends adapter topics for safe schema migration, universal correlation IDs for observability, and Debezium for heavier CDC needs.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 3:29API use cases and benefits
- 6:58Event-driven use cases and benefits
- 9:05Trade-offs: API vs events
- 14:01Mitigating trade-offs with API-first
- 21:42Event migrations and observability
- 25:34API-first event-always architectures
- 26:36Key takeaways
- 27:03Q&A: Event data and unused events
- 28:29Q&A: CRUD vs domain events
- 29:31Q&A: Change data capture tools
- 30:31Q&A: Event granularity
- 31:13Q&A: Scalability and loose coupling
related talks
31mDemystifying Event-Driven Architectures
26mAPI Management, meet Event Management
34mMaximizing the Value of Your Event Driven Architecture
25mAccelerate Event Enabling the API Economy
26mMetamorphosis: Microservices & Event-driven Architecture
26mEvent Driven APIs
17mBringing the Power of APIs to Event Driven Architecture
01h 08mEvent Driven Architecture – Enabling Microservices