Transactions in Microservices

A microservice does a business unit of work. Transaction boundaries in most cases will span a business unit of work; hence, the transactions are automatically contained within a service. For example, a "debit savings bank account" operation can be atomic and transaction integrity can be ensured as that operation is within the boundary of service.

However, there are business scenarios that require you to run business units of work across multiple services, written by different teams in different domains.  Since such orchestration spans across boundaries of multiple services, ensuring transaction integrity is a challenge. There are multiple strategies to address this challenge.  

Taking a concrete example of online "credit card bill payment" that we all familiar with, bill payment requires orchestration of two operations, "debit savings bank account" and "credit to credit card account" which are handled by different domains. In this case, "credit card bill payment" is a composite operation across two services.  The debit and credit operations should happen together or not happen at all. So that leads to the classic architecture challenge, how do we ensure transaction integrity of operations that are performed across services that are distributed.

Our instinct is to think of distributed transactions as the strategy coordinated by a composite service "credit card bill payment." However, distributed transactions are wrought with scalability and stability issues, like deadlock concerns and hence not recommended.

Compensating Transactions

A more viable strategy is to see the "credit card bill payment" execute the two operations independently. If the composite service detects a failure in credit operation after executing debit operation, it will have to reverse the debit operation by posting an equivalent credit entry. This credit entry is a compensating transaction. 

However, there are scenarios that can affect the transaction integrity with the compensation strategy. One of the scenarios is when composite service fails after executing a debit operation before it can execute credit operation. Multiple patterns can be used to handle failure during the transaction. We will discuss three patterns:

• State Store.
• Routing Slip.
• Process Manager.

State Store

Composite service records all the state changes in a state store. In case of failure, state store can be used to find and recover incomplete transactions.

Routing Slip

Another popular resilient approach is to make composite "credit card bill payment" operation asynchronous. Composite service creates a message with two request commands (a debit and a credit instruction) in a routing slip. This message is given to the debitSavings service from the routing slip. The debitSavings service executes the first command and enriches the routing slip before handing message to credit service that completes the credit operation. If there is a failure, the message is sent to an error queue, where the composite service can look at state and error status and compensate if required.

Process Manager

An alternative to routing slip approach is the Process Manager, which listens to events generated by Debit and Credit Operations and decides on compensating or completing the transaction.

Collapsing Operations Within the Same Bounded Context

Taking another example, inter-account transfer between two savings accounts can be traditionally done by calling "Savings Account" microservices twice, viz. once for the debit of origin account and the second time for crediting destination account. It brings similar transaction considerations discussed above. However, in this case, since both debit and credit operations happen on same domain "Savings Account" the "Account Transfer" logic can reside in the same microservice that runs debit and credit operations.  This simplifies transaction boundaries.

Conclusion

Thus, we discussed various patterns to handle transaction concerns in microservices. Based on your use case, the best approach can be taken forward from the above options.