0
votes

As per what chrisrichardson wrote about compensating transactions in sagas in microservices:

What are compensating transactions?

The rejectOrder() command is an example of a compensating transaction. Unlike ACID transactions, sagas cannot automatically undo changes made by previous steps since those changes are already committed. Instead, you must write compensating transactions that explicitly undo those changes. Each step of a saga that is followed by a step that can fail (for business reasons) must have a corresponding compensating transaction.

In the Create Order Saga, createOrder() has the rejectOrder() compensating transaction because the reserveCredit() step can fail. The reserveCredit() step does not need a compensating transaction because the approveOrder() step cannot fail. And, the approveOrder() step does not need a compensating transaction because it’s the last step of the saga.

Does this literally mean that a step won't need a compensating transaction as long as its following step doesn't fail for business reasons? What if the following step fails for some technical reasons -- some bugs or some inter-microservice communication issues e.g.?

1
if you expect any failure in any step, you should wrap it into transaction, which will save your day in the future. dont look if it is because business logic or technical problem - Filip Kováč
when there are network communications this is not an option, because in case of failure the service cant do rollback because it doesn't happen in a database transaction, if the network communication has changed the state in the other microservice and then, other call fails the first one can't be rolled back - JArgente

1 Answers

0
votes

This is because, if there cant be business errors you can retry the communication or schedule it when the technical issues are solved, and when it happens the state will be correct.

Keep in mind that technical problems are transient and in a microservices architecture you have to deal with eventual consistency