[question] event of chain rollback

[archenroot]

Hi guys, how do you handle following scenario?

Order of events:

1. Booking Flight -> succeed
2. Booking Car -> succeed
3. Booking Hotel -> failure (room not available)

How to rollback those in as much as possible generic way? The key lies in what you call correlation or global transaction ID, which should be same in all events. So I should be able to send failure event to both booking car and flight with this global transaction id and they will independently revert the booked flight and car.

That way it can work, but it has one negative drawback

This way it will require each service to listen to failed events of all next services in chain, so each service will have implement event handlers for failed messages from all "next" services in process chain, on top the TCP overhead can be also deadly.

So probably better solution will be to do step-by-step rollback and not massive one:

I have studied sagas, but I didn't find clear answer on this common handling scenario...

The only problem with second design I see that it doesn't make sense from business perspective as when hotel failed, both cars and flights should be canceled in parallel.

[archenroot]

As I think this is quite confusing even on publicly available articles, I will put here few things. Thing is that Saga is sometimes shown or interpreted as orchestrator (Saga, Process managers) which is confusing and is wrong. Event driven is about removing so called orchestrators, but more looking from choreography perspective....

Saga is more a error management pattern in event driven architectures, so every Event in the system has its corresponding opposite UndoEvent. And this is application of saga pattern.

going futher into problematics, what if the UndoEvent fails. If I say Event can fail and I generate UndoEvent, what if this UndoEvent also fails.....??? It suggest that there is a bug in implementation, but how to handle this properly in production system?

[GavinChenYan]

yes, I think for the scenario you mention, we should use saga to do step-by-step rollback.

For the case if the undoEvent (or compensating transactions) fail, I think we will have to handle it in the service ifself. For example save the correlationId to local database, or send email to admin?

Totally agree with you, it will be very complex to handle compensating action fail again.

[archenroot]

@ChenYan71 nice, thanks for confirmation about my thoughts. So actually this is also answer that the functional analyst while designing the flow, he/she should always design the opposite process, while developer uses light platform to develop on top of it.

Thanks for feedback.

[stevehu]

Like you have mentioned, there are two ways to implement Saga - Orchestration and Choreography. There are pros and cons on both. For a small and simple system, choreography might be easier to start however, every aggregate needs to know how about the saga and actively manage the business logic. Also, in a complex application, you might have circular dependency issue. For big system, it is better to use orchestration so we can implement aggregates as simple as possible. Also, the centralized console/admin can give operation team an overview what is going on and resolve the issue like failed rollbacks you raised above. Our saga implementation is embedded with a library so we can support both approaches although I myself prefer orchestration for enterprise scale.