API First or Events First: Is it a Binary Choice?
summary
A decision tree and actionable heuristics tie choice to cost, latency, security, and external integrations: start with API gateways then events for consumer-driven modernization, emit thin vs thick events (or use thick events to avoid API callbacks), adopt CQRS and event sourcing only for high-value consistency needs, and use saga / docket choreography for multi-step processes like driver onboarding or food-order flows. Tools and patterns mentioned include Kafka, stateful event streaming for aggregation/windowing, Protobuf/Confluent schema registries, and local query views versus eventual consistency tradeoffs.
AI-written summary · about
chapters (17)
- 0:00Introduction and speakers
- 0:46APIs vs events overview
- 1:08Fundamental differences explained
- 2:11Business imperatives of APIs
- 3:15Business imperatives of events
- 4:39Events maturity model
- 6:25Decision heuristics for architecture
- 7:27Evolving from monolith to microservices
- 9:54Backward compatibility and contracts
- 11:20Analogies between APIs and events
- 13:29API maturity models explained
- 16:58Combining APIs and events in systems
- 18:43Saga pattern and choreography
- 21:30Stateful event streaming
- 22:56Modernizing batch processes
- 23:17Recommendations and next steps
- 24:41Q&A and conclusion
related talks
27mPatterns for Event-Driven APIs
48mAsynchronous Web APIs in an Event Driven Architecture: when to use what
32mUnifying API and event driven architectures
26mMetamorphosis: Microservices & Event-driven Architecture
45mCommon quandaries implementing your first Event Driven Architecture
27mOptimize Your API with Event-Driven Microservice Architecture.
39mBuilding next-gen applications with event-driven architecture
46mEvent-Driven Microservices - not (just) about Events!