10.5 Orchestration-Based Sagas
Centralise responsibility for a saga in a single serviceThis pattern is based on the original behaviour of Sagas [172], and defined as Orchestration by Rotem-Gal-Oz [13, p. 170], Richardson [20, p. 121, 173], Newman [3, p. 189], Azure [174], and Deenadayalan [182].
Process Manager by Hohpe et al. [4, p. 278], Workflodize by Rotem-Gal-Oz [13, p. 35], and Scheduler Agent Supervisor by Microsoft [183] implement a similar concept but do not discuss failure management; if such they imply failing-forward.
10.5.1 Context
A Saga (see § 10.3) needs to be implemented, but the interactions between services are complex, many in number, or need to be independent. It is desirable to have the workflow defined and monitored in a single place.
10.5.2 Solution
Implement or appoint a central Orchestrator that operates a state machine describing the saga (see fig. 32). The orchestrator sends commands to the services involved in the saga, instructing them on what to do next. The services then respond with the outcome of the operation.
10.5.3 Potential issues
Using an orchestrator may lead to increased coupling between it and the services. Implementing it as a new service to manage the saga leads to increased complexity. The orchestrator can become a single point of failure and introduces a risk of centralising business logic in a single service.
10.5.4 Example
As the order processing in ExampleEshop involves a complex process and multiple services, they decided to use a central orchestrator to manage the process. The orchestrator is responsible for coordinating the services and triggering compensating transactions in the case of a failure by implementing a state machine. This way, the process is readable and easily changed or extended. As it waits for external services for most of the process, the orchestrator uses asynchronous programming to run multiple sagas concurrently. It also logs each step in the process, which can be used for debugging or analytics.
10.5.5 Related patterns
- Choreography if the number of services is small (see § 10.4)