using saga pattern with compensatting transactions

[Jignesh Patel]

While using microservices it is recommended to use a saga pattern with two different microservices doing two different transactions.
I have the following use case.
A patient gets discharged from the hospital, now there are two different services connected to two completely different databases(don't ask me why, as that is a technical constraint). The first microservice says I have successfully discharged you but the other one fails. Following the saga pattern now system needs to execute the compensating transaction, which is to reject the discharge, but the discharge is already done, and rolling back is quite a difficult task as there are so many things happening in that particular system for the discharge. What could be possible options? for that?

[Stephan van Hulst]

It depends on what the second transaction is and whether it's retryable and/or compensable.

If the second transaction is retryable, simply retry until it commits. If it isn't, but if it's compensable, then you might want to execute the second transaction first, and if it commits, only then perform the first transaction.

[Claude Moore]

Jignesh Patel wrote:While using microservices it is recommended to use a saga pattern with two different microservices doing two different transactions.

To be more precise:  microservices normally use local ACID transaction; SAGA pattern is used to achieved eventual consistency, i.e,  to ensure that at the end of a distributed transaction spanning over multiple microservices,
the whole system in in a consistent state.

Jignesh Patel wrote:
I have the following use case.
A patient gets discharged from the hospital, now there are two different services connected to two completely different databases(don't ask me why, as that is a technical constraint). The first microservice says I have successfully discharged you but the other one fails. Following the saga pattern now system needs to execute the compensating transaction, which is to reject the discharge, but the discharge is already done, and rolling back is quite a difficult task as there are so many things happening in that particular system for the discharge. What could be possible options? for that?

SAGA pattern isn't a real replacement for Distributed ACID transaction, that more or less are unfeasible or at least very expensive to handle in a microservice based architecture, so there isn't a real commit and there is not, of course,
a real rollback. You have to handle it by hand. Stephan  suggested a viable option - execute first local transactions that are more prone to rollback or that may be easily rolled back, then execute all others transaction, or simply retry.

Most often, if the microservice based software is carefully designed, business transactions handle some logical state; in your case, system A (which accepted dismission of the patient) should handle the fact that system B rejected dismission, and mark patient's status as "Pending" until  system B somehow manages to confirm the dismission. By the way, for the Single Responsability Principle, a single microservices should be responsible to handle the status of a patient; this seems not to be the case; so the design seems to be a bit flawed.