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 <eric.lee....@gmail.com> 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
>

Reply via email to