Sagas are coordinated in two ways:
Through Orchestration - a target service (can be a standalone or a participant in the transaction) is designated as the coordinator of the steps/state to complete a set distributed transaction by invoking/emitting events to other services either asynchronously or synchronously.
Through Choreography - each service invokes/emits an event that prompts the next service in line to complete its transaction either asynchronously or synchronously.
Distributed transaction matrix | ||
|---|---|---|
Communication | Consistency | Coordination |
Synchronous | Atomic | Orchestration |
Synchronous | Atomic | Choreography |
Synchronous | Eventual | Orchestration |
Synchronous | Eventual | Choreography |
Asynchronous | Atomic | Orchestration |
Asynchronous | Atomic | Choreography |
Asynchronous | Eventual | Orchestration |
Asynchronous | Eventual | Choreography |
Saga State Machine for scenarios
To better visualize the state transitions you can refer to the "Vessel Registry Controller Microservice: Saga Orchestrator" post to get more details. We will omit that section from this document as it is well documented there.
Saga Pattern Implenation 1 - Synchronous / Atomic / Orchestration
Pattern Description
An orchestrator in this case the VRG coordinates the workflow of the involved services. All communication in this workflow are synchronous. The transaction boundary specifies that the transactions will either all succeed or none will. If one of the services involved in this workflow, fails, the orchestrator issues compensating calls to the preceding services to undo the changes that were made, as shown in the “Transaction Failed Path” diagram (Red Lines).
Pattern Characteristics | |
|---|---|
Coupling | This saga pattern implementation exhibits high degree of coupling. This pattern closely resembles the communication style of a monolithic application. |
Complexity | Low level of complexity are associated with implementing this pattern, because it reduces the chances of race conditions and deadlocks. |
Responsiveness/Availability | Due the coordination done by the orchestator and the synchronous communication it will exhibit bottlenecks, and reduced performance under high loads. There is also a high chance that this implementation will fail when the services the orchestrator coordinates during the workflow are in an unrecoverable error state. |
Scale/Elasticity | Due to the communication style and coordination, scaling this pattern will prove to be difficult. |
Saga Pattern Implenation 2 - Synchronous / Atomic / Choreography
Pattern Description
In this particular saga pattern implementation (choreography) there is no central orchestrator to conduct the workflow, rather, the initial request is initiated by what is called a front controller, in this case it is the VDS service. After successfully completing their work, the services will begin invoking the other service(s) that come after them, all the way until the last service has been reached, which will then return the result. If however, an error was to occur, then each service must have built-in compensating logic, to send requests back along the chain to the front controller.
Pattern Characteristics | |
|---|---|
Coupling | Since this pattern uses a choreographed approach but still uses synchronous communication, the coupling is reduced slight. It is slightly reduced because of the transactional requirement which must be distributed across the different services. |
Complexity | This pattern exhibits high level of complexity because of the built in compensating logic in each of the services involved in the workflow. This will most likely continue to increase as new services are added or removed. |
Responsiveness/Availability | Slightly increased because of the lack of orchestration, but would be diminished quite rapidly because of the built in compensating error correction logic. |
Scale/Elasticity | Scalability for this pattern is slightly increased because of the lack of bottlenecks as a result of orchestration. However this pattern’s implementation is synchronous and exhibits tight coupling, and if deployed in an environment which has high error rates, then the scalability is greatly diminished. |
Saga Pattern Implenation 3 - Synchronous / Eventual / Orchestration
Pattern Description
This pattern re-introduces the orchestrator whose sole responsibility is to coordinate requests, responses, and error handling. The responsibility for managing transactions is delegated to the domain services. This frees up the orchestrator to issue compensating calls but without being bound within any active transactions.
The main benefit for this type of approach is eventual consistency which alleviates the coordination challenge related to error handling.
Pattern Characteristics | |
|---|---|
Coupling | Introducing the orchestrator brings back high coupling, but removes atomic transactions which alleviates some of the complexities associated with managing workflows. |
Complexity | Easy to implement because of the synchronous/orchestrated approach, and the removal of atomic transactions. |
Responsiveness/Availability | Because the orchestrator is no longer tightly involved in the transaction boundary of the domain services, it allows it to better load balance. |
Scale/Elasticity | Because the transaction boundaries are restricted to the domain services it will be much easier for them to scale more independtly. |
Saga Pattern Implenation 4 - Synchronous / Eventual / Choreography
Similar to the previous saga pattern implementation (Pattern 3), the difference here, is there no central orchestrator managing the workflow of the participating services. However, it does retain the service scoped transaction boundary and eventual consistency approach.
Each of the participating services will:
Accept incoming requests
Complete the actions associated with the service
Forwards the request to the next service in the flow
One of the benefits of this approach is the ability for each service to implement the Chain of Responsibility design pattern, where each service in this approach is responsible for its own transaction. Since the transaction boundary is encapsulating the service itself, the error correcting logic must be placed within the participating service domain.
Pattern Characteristics | |
|---|---|
Coupling | Reduced due to the lack of an orchestrator. Still exists because of the synchronous communication that exists between the services. |
Complexity | Reduced because of the lack of compounded transaction boundaries. |
Responsiveness/Availability | Fast for one-way communication, but will experience issues in an environment where high error rates exist. This is because each service must recover after an error and bring the state back into a normal zone (Eventual). |
Scale/Elasticity | High scaling and elasticity options with this implementation and as we will see in the upcoming implementation, can be improved with asynchronicity. |
Glossary
Term | Definition |
|---|---|
Atomic | |
Bottlenecks | |
Elasticity | |
Eventual Consistancy | |
CDS | Client Detail Service [Microservice] |
VRG | Vessel Registry Gateway [Microservice] |
VDS | Vessel Detail Service [Microservice] |
VRS | Vessel Registry Service [Microservice] |
WMS | Workload Management Service [Microservice] |
Sync | Synchronous communication |
Async | Asynchronous communication |
Pipes and Filter Architecture Style | A workflow with a one-way series of steps. |