Movin beyond request-reply: how smart APIs are different
summary
Microservices are distributed and fail unpredictably, so the talk argues for stateful retry and client-generated transaction IDs for idempotency; a workflow engine (examples: Camunda, AWS Step Functions) persists state, waits for hours or days, retries, escalates, and recovers processes like barcode generation or payment cleanup. Circuit breakers protect downstream calls, asynchronous commands let orchestration manage an order flow, and pure event-choreography often becomes a hard-to-debug “pinball” system.
AI-written summary · about
chapters (21)
- 0:00Start
- 4:32Current situation – the good part
- 5:46Current situation – the bad part
- 9:59You can use a workflow engine =durable state machim
- 13:50Requirement: Idempotency of services!
- 14:33Make every service idempotent!
- 18:03Distributed systems introduce complexity you have to ta
- 19:37Example
- 21:53who is responsible to deal with problems?
- 22:18Long running services
- 24:27Asynchronous communication
- 25:06Workflow...
- 25:48A workflow engine enables long running behavior
- 28:03Event-driven
- 29:15Peer-to-peer event chains
- 30:49Pinball Machine Architecture
- 33:20Choreography
- 35:23Events & Commands
- 36:04Long running orchestration
- 36:36Workflows live inside service boundaries
- 47:01Thoughts on the state machine workflow engine marl
related talks
51mComplex Event Flows in Distributed Systems
48mLost in transaction?
44m3 common pitfalls in microservice integration and how to avoid them
40mCommunication between (micro-)services
33mAutomating Processes in Modern Architectures
47mComplex event flows in distributed systems
38mDurable Execution: The Next Leap for Microservices Architectures
36mLost In Transaction