Saga

Saga is ACD (Atomicity, Consistency, Durability) Traditional approach(2PC, 3PC 2) to distributed transaction management isn’t an option, see details in 1

Challenges

• 2023101222375656 Lack of isolation between sagas
• Rolling back changes when an error occurs

Coordinating sagas

Choreography

• 💡 Issue: you need to use a transactional outbox to ensure that a message achieves message broker.
• 💡 Issue: you need to use correlation id, for example Order Id, do identify message information with database entity in the service.
• ✅ Simplicity: Services publish events when they create, update, or delete business objects.
• ✅ Loose coupling
• ⛔ Difficult to understand: There isn’t a single place in the code that defines the saga.
• ⛔ Cyclic dependencies between the services
• ⛔ Risk of tight coupling

This approach is better suitable for simple sagas.

Orchestration

• 💡Use a state machine to model a saga orchestrator
• 💡Issue: you need to use a transactional outbox to ensure that a message command achieves message broker.
• ✅ No cyclic dependencies between the services
• ✅ Less coupling. Services just implemented command and doesn't need to know about all events
• ✅ Easier to understand
• ⛔ Risk of centralising too much business logic in the orchestrator

Example:

References

1. Microservices patterns by Chris Richardson, chapter 4
2. https://en.wikipedia.org/wiki/X/Open_XA
3. http://microservices.io/patterns/data/saga.html