Co-ordinating data changes in distributed systems
summary
Asks how to make multi-service changes atomic and shows a working Go-based orchestration saga: a change orchestrator publishes commands to profile, vehicle and policy channels and listens on a reply channel, using a simple state-machine switch to advance steps. Uses message brokers (RabbitMQ/Kafka/EventBridge suggested), revision-based rollbacks plus optional distributed locks, and enforces transaction IDs and idempotency. Code exists as a beta GitHub repo and the approach proves viable but requires observability and careful failure handling.
AI-written summary · about
chapters (6)
- 0:00Start
- 0:07Changing data is easy!
- 6:16Implementing the Orchestration Saga Pattern
- 14:40Use unique transaction IDs
- 15:50Provide the data to the services
- 16:40Observe your Sagas
related talks
44mGetting started with Orchestration and Choreography in Distributed Applications
51mNot Just Events: Developing Asynchronous Microservices
51mPatterns & Practices of Implementing Event-driven MicroSvc...
51mComplex Event Flows in Distributed Systems
47mComplex event flows in distributed systems
27mEmpowering Resilient Scalability: The Power of Choreography in Distributed Systems
26mFrom Chaos to Choreography: Multi-Agent Orchestration Patterns That Actually Work
57mEvent Driven Collaboration