Patterns for Event-Driven APIs
summary
Defines concrete patterns: single event-emitting APIs, buffering with RabbitMQ / AMQP or MQTT queues, and landscape-level shared brokers like Kafka that decouple producers and consumers. Argues for infrastructure (marketplaces, WebSocket/SSE gateways for external users), recommends CQRS for separating commands and events, and limits event sourcing to critical subsystems (banking ledgers as example) rather than whole systems. Emphasizes choosing the pattern by business need, not hype, and notes IoT sensor and withdrawal events have very different reliability requirements.
AI-written summary · about
chapters (9)
- 0:00Start
- 3:15Have we reached Peak API?
- 7:57The Event Spectrum
- 11:19Advanced Message Queueing Protocol (AMQP)
- 13:19Message Queue Telemetry Transport (MQTT)
- 14:41Event Architecture: Managed Queues
- 17:41Event Architecture: Event Landscapes
- 21:37Command Query Responsibility Segregation (CQRS)
- 23:45Event Sourcing: Events Represent State
related talks
53mPatterns of Event Driven Architecture
26mEvent Driven APIs
31mDemystifying Event-Driven Architectures
52mSo You Want to Build An Event Driven System?
27mGetting started with Event-Driven APis
41mGetting started with Event-Driven Architectures in 2023
48mEvent-Driven Architecture – Benefits and Pitfalls
54mSo You Want to Build An Event Driven System?
