10.4 Choreography-Based Sagas
Distribute responsibility for a saga across participating servicesThis pattern is based on Choreography by Richardson [20, p. 118, 173], Newman [3, p. 192], Microsoft [174] and Deenadayalan [181].
Hohpe et al. [4, p. 284] consider this a distributed Pipes and Filters.
10.4.1 Context
A Saga needs to be implemented (see § 10.3), and the interactions between services are simple or few. The services need to be autonomous and have local control. A central orchestrator (see § 10.5) would be an unwanted single point of failure in the system.
10.4.2 Solution
Services pass each other events using Publisher–Subscriber or Queue-Based Load Levelling. They move the transaction forward on receiving successful events and roll back on receiving failure events (see fig. 30).
10.4.3 Potential issues
Using choreography means no single place documents the entire process, which may make it hard to understand. This can make it unsuitable for complex sagas.
It can also make it harder to monitor the state of the process – one solution is to use a Correlation Identifier [4, p. 154, 63] and log all events passed through the system [3, p. 193].
Regarding development, choreography can lead to cyclic dependencies or tighter coupling between services [20, p. 121].
10.4.4 Example
ExampleEshop screens and compresses attachments in a review. This process is composed of several steps and needs to be separated into different services, either because of security or different hardware requirements.
The review attachment repository saves the attachment and creates a new message with a Claim Check token
The spam and inappropriate content filter checks the attachment
The image processing service compresses the attachment
The review is added to the database
The services communicate with each other using a message broker and subscribe to the events needed to move the process forward (see fig. 31).
10.4.5 Related patterns
- Orchestration if the interactions are complex or there are many services (see § 10.4)