Event-Driven Microservices - not (just) about Events!
summary
Events often mask hidden two‑way dependencies and copying of business rules, so choose message types deliberately: events introduce implicit coupling for durable facts, commands for one‑to‑one side effects, and queries for information (point‑to‑point or scatter‑gather). Advice includes event sourcing vs event processing, using an event store that supports per‑aggregate append and full sequential reads, and pragmatic tech choices (Axon Framework / Axon Server built for routing by stereotype, RabbitMQ/Kafka, MySQL, Spring Cloud Eureka). Naive “route everything” designs work in labs but fail to scale.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 1:07Architectural problems
- 4:08Caching limitations
- 5:58Big ball of mud
- 6:27Microservices challenges
- 7:21Evolutionary approach
- 7:48Introducing CQRS
- 15:09Designing for messages
- 39:31Axon framework
- 40:04Bounded context
- 41:38Summary and conclusion
related talks
44mEvent-Driven Microservices, the Sense, the Non-sense and a Way Forward
47mEvent-Driven Microservices = Microservices Done Right
31mThe Power of Event-Driven Systems without Burning your Hands or Budgets
01h 12mDemystifying "event-based" software concepts and methodologies
58mImplementing Event-driven Microservices
31mDemystifying Event-Driven Architectures
54mDemystifying ‘Event’ Related Software Concepts and Methodologies
57mEvent Driven Collaboration