...
Similar to the previous saga pattern implementation (Pattern 3), the difference here, is there is no central orchestrator managing the workflow of the participating services. However, it does retain the service scoped transaction boundary and eventual consistency approach.
...
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 A downside however is, since the transaction boundary is encapsulating the service itself, the error correcting logic must be placed within the participating service domain, which will add in complexity.
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. |
...