I prefer #2 option. As I think in our pack implementation, we just send saga_start and saga_end event in the normal Request and Response the happy path. But in the recovery model, it's a challenge that we don't know how to send the saga_end in the right time. It looks like we need to find a way to start and stop the saga explicitly. Any thoughts?
Willem Jiang Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: 姜宁willem On Mon, Mar 5, 2018 at 7:32 PM, Eric Lee <[email protected]> wrote: > Hi, all > > Currently, we encounter some problems in implementing forward recovery in > saga. If we use synchronous API, the error code will respond immediately if > any exception throws. However, the transaction still goes on until it's > done. It may lead to bad experience to the user as user may see view the > wrong results. In Chris Richardson's talk: "Data Consistency in > microservice using saga"[1], he provides two options as follows: > > > Option #1: Send response when saga completes: > > + Response specifies the outcome > > - Reduced availablity > > Option #2: Send response immediately after creating the saga(recommended): > > + Improved availablity > > - Response does not specify the outcome. Client must poll or be > > notified. > > And he prefers the #2 option to use asynchronous API. > > In my opinion, option #2 seems to be more user-friendly. Any other > solutions for this or any comments for these two options are welcome. > > Reference: > [1] https://www.infoq.com/presentations/saga-microservices > > --- > Best Regards! > Eric Lee >
