MicroServices Architecture to Solve Distributed Transaction Management Problem

Problem: Handling transactions that span across multiple services/DataBases.Maintaining ACID (Atomicity, Consistency, Integrity, Durability) properties across Microservices is challenging because each service performs local transactions.

Significant issues with distributed transaction management:

• How to maintain a transaction’s atomicity. Atomicity suggests that all of the steps in the transaction must be successful, or else all of the steps that have already been completed should be rolled back if one fails.A transaction, on the other hand, can be made up of multiple local transactions that are handled by various microservices in a microservices architecture.Therefore, if one of the local transactions fails, how can successful previous transactions be rolled back?
• How to control the level of transaction isolation for concurrent queries. The transaction isolation level specifies the amount of data visible to a statement in a transaction, specifically when multiple service calls access the same data source at the same time. Should the service return old or fresh data if an object from any of the microservices is persisted to the database while another request reads the same object at the same time?

Proposed Solution:

1. TWO-PHASE COMMIT:

Distributed transactions can also be implemented with microservices using this pattern.There is a controlling node that houses the majority of the logic and participating nodes (microservices) on which the actions are carried out in a two-phase commit.It functions in two stages:

• Prepare phase (Phase 1):The controlling node queries all participating nodes to see if they are ready to commit. Yes or no responses are given by the participating nodes.
• Commit phase (Phase 2):If all of the nodes responded in the yes, the controlling node requests that they commit. Even if one node responds negatively, the controlling node requests a rollback.

The number of phases has an effect on overall performance as well.Since any ready node must wait for confirmation from a slower node, the entire system is constrained by the slowest resources due to the coordinator’s chattiness.Additionally, the synchronous nature of typical implementations of such a coordinator can result in decreased throughput in the future.

2PC still has the following Shortcomings:

• There is no way to roll back the other transaction if one microservice goes down during the commit phase.
• The confirmation of other services must wait until the slowest service has finished.The services’ resources are locked until the entire transaction is finished.
• Due to the fact that they are dependent on the transaction coordinator, two-phase commits are designed to be slow.In particular, in a roll-back scenario involving many services and a microservices-based application, this can result in scalability issues.

For Implementation Refer these :

• Use Commit and Rollback to Manage MySQL Transactions in Python — Python
• How to handle MySQL database transactions with NodeJS — NodeJS

2. Saga Architecture

Using a series of local transactions, the Saga pattern manages transactions that span multiple Microservices.The reverting transactions are mostly referred to as “Compensating Transactions/Action”.

A compensating action has the ability to reverse any action in the Saga.The Saga guarantees that either all operations are successfully completed or that the appropriate compensation actions are carried out for all operations to undo any previous work.

We will need to implement the Saga Execution Controller in order to ensure the stability of the system. This controller makes sure that the compensating queries are triggered in the event of a failure.

It determines the rollback events in the event of a failure and keeps a sequential record of all distributed transaction events.

Also, the SEC makes sure that rollback events do not have any additional effect other than reversing the local transactions.The Compensating transactions are supposed to be idempotent and retryable.The sequence of executing compensating queries should be the opposite of how the original transactions occurred.

Note: SEC internally uses a ‘stack/log’ named Saga log to keep track of all transactions

Well , I wanted to Implement SAGA Arch for an API which transacts on Multiple DBs, So I made few changes to suit my needs .

Attaching a flowchart on how I Implemented it

So that’s how you do it ,Thanks.