Microservices : Distributed Transaction Management — 2 Phase Commit (Part 3)
For distributed transaction management in Microservices architecture we have seen following patterns in part 1 and part 2 of this article –
2. Abort All
A common protocol to handle distributed transactions is Two Phase Commit (2PC). As name suggests this protocol breaks a transaction in to 2 parts. First let’s understand the concept of 2PC protocol in transaction context, then we’ll see a real-world scenario as well where it may fit.
In a 2PC protocol there is a transaction coordinator that will commit transaction to the database in the following steps –
First coordinator will prepare all the transaction and during preparation it’ll block the resources participating in the transaction, until the complete transaction either completes or roll back. Once all the transactions are prepared, then coordinator commits them, in event of any failure the complete transaction is rolled back.
How coordinator performs this series of steps, let’s take an example where there are 3 different DBs are part of one transaction, coordinator will send a PREPARE message, one for each DB, every individual DB responds back to the coordinator with “READY” message. Once coordinator receives READY message from all the participating DBs, it sends a COMMIT message to all the DBs and each DB then responds back with DONE message.
During this whole process, any individual DB if it’s not READY or doesn’t respond back with DONE during prepare or commit phase respectively, coordinator will abort the complete transaction.
Now let’s see a practical example of this in Microservice context. I am taking an example from online shopping scenario, the Create Order process (if you are reading this, you must be familiar with this ) and see how 2PC pattern fits in –
If you follow the diagram above, the coordinator service initiates the transaction with a unique identifier let’s say Tx1 (not so unique, I guess but will serve the purpose here). Now coordinator service coordinates all the transactions involved in this process. Every other microservice, let’s say has its own database and coordinator will first call Wallet service and ask to mark X amount of fund blocked for Tx1. Coordinator will also call Order service to create an order for Tx1.
Now let’s say there are not enough funds in the wallet, so Wallet service will not come back with the successful response, and coordinator will abort the whole transaction.
But let’s assume that Wallet Service and Order service both comes back with successful response then coordinator will initiate the next phase and calls these services to commit the transaction. Once both the service commits the transaction and respond back with successful response, coordinator will end the transaction Tx1. If during commit phase something fails, coordinator will abort all the transactions happened till then associated with Tx1.
2PC guarantees atomicity and read/write isolation. It ensures the data is consistent and all the data is synchronized all the time. Despite its benefits, it’s not recommended in many situations due to its synchronous nature. 2PC protocol is blocking protocol and has a single point of failure too. If transaction coordinator fails, the DB will be in an inconsistent state, also due to multiple transactions, latency is high, and the complete system will be as slow as the slowest transaction in the whole process.
All the systems which have the limitations as explained above are good candidates for implementing Saga pattern. In next part we’ll talk about Saga pattern for distributed transaction management. Stay tuned.
Till then Happy Reading :)
