Convenor: Bernd
The Saga pattern describes how to solve distributed (business) transactions without two-phase-commit. The basic idea is to break the overall transaction into multiple steps or activities. Only the steps internally can be performed in atomic transactions but the overall consistency is taken care of by the Saga. The Saga has the responsibility to either get the overall business transaction completed or to leave the system in a known termination state. So in case of errors a business rollback procedure is applied which occurs by calling compensation steps or activities in reverse order.
Implementation can be a Process Manager
Process Manager does not necessarily mean you have a "central" BPM engine, but can be embedded in each microservice.
Microservices might communicate via event bus (Kafka, Rabbit, ...). This case typically the consumer is coupled (I know I have to listen to event X) and not the sender (I know I have to call X now). It is typically more flexible to add new consumers then. Compensation chains might be tricky to implement without coupling in two ways.
Direct communication between the services means you couple it tightly and you have to reverse from the next to previous.
BPM could help with it to orchestrate.
Example of "ebay-like" service:
- Send avro messages which have a Schema
- Kafka underneath
- No orchestration, but "it is a mess"
- Hermes keeps track until which point the messages have been consumed and pushes them to the service
- Have another service listening to all the events to have a state