Designing for Autonomy
summary
Argues that autonomy comes from publishing facts not RPC: services emit events, other services build local state and respond, so systems survive slow or down dependents. Recommends a process manager as a stateful subscriber that issues commands, holds a state machine for ticket reservation-like workflows, and records failures. Suggests event sourcing or at least persisting events, using projectors/read models and replay/rewind to rebuild answers. Notes PHP can work but avoid full frameworks for long‑running consumers; restart processes to avoid memory leaks.
AI-written summary · about
chapters (30)
- 0:00Introduction
- 0:28Microservices
- 2:30Microservice envy
- 4:32Advantages
- 5:53Autonomy
- 7:28What could go wrong
- 8:22The first time this happened
- 10:06Doctrine 1 Cache
- 11:57InterService Communication
- 13:45Reactive
- 14:55Redistribution of knowledge
- 16:23Nobody is listening
- 17:46Manager
- 18:12Process Manager
- 18:39State
- 22:04State Machine
- 24:11Queries
- 24:24Other services
- 25:14Query
- 25:48Current State
- 26:16Events
- 27:10Dependency
- 27:56Event Sourcing
- 29:20Event Dispatch
- 30:02Replay Rewind
- 32:03Conclusion
- 33:06Microservice
- 33:30Not all black and white
- 35:19Martin Fowler
- 37:20Migration
related talks
54mHow Events Are Reshaping Modern Systems
59mEffective Microservice Communication and Conversation Patterns
39mManaging Consistency, State and Identity in Distributed Microservices
52mMovin beyond request-reply: how smart APIs are different
57mReliability Nirvana
49mReactive microsystems
25mNo Return: Moving beyond transactions in software and in life
55mGoing Resilient