Considering DYI Saga implementation vs BMP workflow-based one? Here are some points I recommend to take into account (thread, 1/8)
#sagapattern #distributedsystems
BPM workflow takes the responsibility of state changes, message delivery, and some error handling. Those cover a few of the tricky corner cases, that normally would need to be handled manually (2/8) https://twitter.com/gunnarmorling/status/1345305161015717888
(3/8) https://twitter.com/mikemybytes/status/1345329609181687809
At the same time, BPM workflow comes with a cost of additional complexity and various limitations. If there is no experience with such tools, adding one to the stack may be a significant effort (4/8) https://twitter.com/mikemybytes/status/1345330426773123077
Handling all possible types of errors & failures is probably the most tricky part of the Saga implementation. Would the BMP workflow engine take care of them all? (5/8) https://twitter.com/mikemybytes/status/1345106813948104704
Creating a DYI solution is a complex & error-prone task. Deep technical & business understanding is a must. As well as careful testing of it (6/8) https://twitter.com/VictorRentea/status/1345289457612808192
Saga is already difficult on its own. Adding a BPM workflow-specific notation on top of it may make it even more complex or hard to understand, depending on how the process being modeled looks. Keeping things simple is rarely a bad thing! (7/8)
IMO the decision about how to implement Saga should be based on the process complexity (especially the number of participants), understanding of the distributed systems problems, and the tooling experience. There is no silver bullet - each solution brings its own trade-offs (8/8)
You can follow @mikemybytes.
Tip: mention @twtextapp on a Twitter thread with the keyword “unroll” to get a link to it.

Latest Threads Unrolled:

By continuing to use the site, you are consenting to the use of cookies as explained in our Cookie Policy to improve your experience.