I could be wrong but I think the following scenario is worth considering. Let's say a client wants to transact money from bank A to bank B. The following steps are taken:
1. Client initiates the transfer request.
2. Bank A decreases the client's balance.
3. Bank A sends the request to transfer money to bank B.
Now, I guess you would expect that steps 2 and 3 should form part of a DB transaction. This however does not really work because it is unclear what conclusion we should draw from step 3 failing. On one hand, it is possible that the request failed on its way to bank B, in which case step 2 should not be applied. On the other hand, it is possible that the request successfully reached bank B but the response got lost on its way back. In this case step 2 should be applied.
Therefore, not treating steps 2 and 3 as a single transaction makes sense if you want to take a conservative approach that does not allow for accidental transfer of infinite amounts of money to bank B in scenarios when the response fails to come back from an otherwise successful transfer.
We have exactly the same problem at work. One possible way to solve it is by ensuring that the receiving system treats the request as idempotent. One could also poll first at the receiver whether the transaction exists, and then send it if it doesn't. But both measures require that there is a way to uniquely identify a request. Also, idempotency can be annoying to implement correctly. Thus, implementors might try to wiggle their way out of it, technically or politically.
1. Client initiates the transfer request.
2. Bank A decreases the client's balance.
3. Bank A sends the request to transfer money to bank B.
Now, I guess you would expect that steps 2 and 3 should form part of a DB transaction. This however does not really work because it is unclear what conclusion we should draw from step 3 failing. On one hand, it is possible that the request failed on its way to bank B, in which case step 2 should not be applied. On the other hand, it is possible that the request successfully reached bank B but the response got lost on its way back. In this case step 2 should be applied.
Therefore, not treating steps 2 and 3 as a single transaction makes sense if you want to take a conservative approach that does not allow for accidental transfer of infinite amounts of money to bank B in scenarios when the response fails to come back from an otherwise successful transfer.