Taming Microservices: How to Manage Distributed Transactions
Microservice-based apps are the hyperloops of Fintech — but up and running on the rails and already increasing productivity and customer satisfaction. No wonder the use of microservice architecture (MSA) is on the rise today.
As fast-and-furious business setting demands constant optimization, new business-oriented services allow market players to profit faster. Maintenance cost and time to market shrink. System parts become more and more atomic to help reduce costs for development support. But as the pace speeds up, new challenges arise too.
One of such complications related to MSA management is handling distributed transactions. This aspect requires special attention when building Fintech products. From our experience, we know that the MSA approach requires skilled teams who have successfully tackled various complications before.
In this article, you’ll find out what difficulties distributed transactions can pose, how to bypass them, and what approaches to use. One of them is the Saga pattern, the implementation strategies of which, along with the pros and cons of each, we discuss in our other piece.
Why managing distributed transactions matters in Fintech
We asked INSART Tech Lead Eugene Pekhulia to explain the importance of distributed transaction management in Fintech. He emphasized the need to pay special attention to the transaction management aspect when building Fintech products. According to Eugene, the main reasons for that are as follows:
- Such a product operates on financial data that needs to be accurate and consistent in every single point of time.
- Most Fintech products have a complex business flow and rules, especially if some of the phases include integration with third-party solutions; in this case, problems with file handling and overall system stability and consistency issues may arise.
- Many ambitious Fintech start-ups attempt to use cutting-edge technologies and architecture approaches; if time to market is the chief priority, transaction management may be not in focus.
- Mature and long-lived solutions were often developed using a monolith architecture approach with traditional transaction management. When they are migrated to microservices, it turns out that simple and familiar transaction management techniques are not applicable in the new architecture style
What’s the challenge
First things first, we’ll start with the basics. If you know what transactions are and what ACID and CAP are all about, you can scroll down to the part about the difficulties.
How transactions work
A transaction is a sequence of information exchange and low-level tasks needed to access and possibly modify the data, such as in updating a database.
Transactions should have a set of properties known as ACID.
- Atomicity—every transaction will complete its execution or not be completed at all.
- Consistency—the result of a transaction is valid data (e.g., the amount of money in an account cannot be negative, the transaction logic must check whether negative values will result).
- Isolation—concurrent transactions will not affect the outcome of other transactions, as if they occurred in a sequence.
- Durability—updates resulting from a transaction must remain persistent even if the system fails or restarts (the money should be in the account).
ACID properties make a transaction reliable: for instance, as a result of such a transaction, a money transfer will be complete and get to the right account, and the balance will not be negative as a result of such a transaction.
Distributed transactions
Ideally, the database would ensure consistency, availability, and partition resistance, but achieving them all is next to impossible in a distributed database system. There, no single node manages all the data that affects a transaction. According to the CAP theorem, in a distributed system, it is possible to ensure only two of the three properties. The database can provide ACID transactions only if it chooses consistency over availability, not the other way round.
If a transaction is unreliable and takes too much time to commit, it can seriously spoil user experience and negatively affect overall system bandwidth.
Below, we discuss when to use distributed transactions and why it might be better to do without them.
