Why is Transaction Management better with Microservices

All real-time computer applications involve transactions. A real-time application would find no use whatsoever without any transactions. We are talking about day-to-day transactions such as sending an email, fund transfers, placing an order, paying a bill, etc. Thus, a transaction is nothing but a unit of work that is performed in any business application that persists data in any state and every unit of work should be committed to ensuring the integrity of the data. 

In this blog, we will discuss the different ways of managing transactions in a distributed microservices environment. The differences in transaction management in microservices, when compared to the monolithic architecture systems, will also be discussed.

Monolithic vs Microservices Architecture Systems

In monolithic applications, during transaction processing, the ACID properties or the four primary properties of atomicity, consistency, isolation, and durability are retained and all changes are performed as if in a single operation. That is, either the changes are performed, or they are not. This guarantees data validity despite power failures or errors. 

The biggest advantage in the case of monolithic applications is the presence of a single and common database server during transaction management. Transactions are initiated at the database level and further can be committed or rolled back based on their outcome.

Read our blog “Microservices at eBay-What it looks like today”.

This method of initiating transactions, performing operations, and persisting or not persisting on the data is easier for the developers to handle. However, this advantage soon turns into a serious challenge while running a high volume of transactions. A small operation on a critical table can lead to the entire application being brought down.

However, in microservices systems, guidelines strongly recommend that you use the single repository principle (SRP), wherein each microservice maintains its own database that no other service should access directly. In microservices, there is no direct possibility of maintaining ACID principles across multiple databases. Herein lies the real challenge of managing transactions in microservices.

Practical Implementation of SRP

Microservices best practices and guidelines strongly recommend that you should use a single database server for every microservice. However, practically this would slightly differ in the early stages of microservices development and are implemented as mentioned below.

• Maintain a set of tables specific to any one service in a database. If you are maintaining all the tables in a single database, attach a prefix or suffix to each table so that it indicates the microservice it belongs to. It is vital to not maintain any foreign key constraints across tables belonging to different services. At the most opportune time, move tables to the specific database server belonging to the specific service.
• You can create and use different database schemas for each service. Here, the schema is named as close as possible to the corresponding service.
• However, in either of these cases, one service cannot be allowed to access the database of the other service directly. In case one service needs data from another service, it should call the service endpoint specific to the required data.

In the case of services that have high demand, it is possible to maintain a common database server across multiple services. This would give rise to possible network latencies while invoking other services. You can solve this problem using data duplication instead of going for a single database server. While data duplication may not allow you to achieve immediate consistency, you can ensure eventual consistency of the data using this method.

Read our blog: Microservices Authorization 8 Best Practices

Handling Transactions in Microservices

The microservices community has, over some time, devised many different ways of handling transactions across different services. Whereas some of the approaches target transaction management at the design level, others do it at both the design and coding levels.

Download and read our eBook for FREE “MICROSERVICES- A Short Guide”.

Given below is a list of the different approaches used for managing transactions. The best part is that we can use one or all of these methods for a given Microservices environment. Also, any two Microservices can use the same approach and another service can follow a different approach for transaction management.

• Avoiding transactions across Microservices

• Two-Phase Commit Protocol

1. XA Standard
2. REST-AT Standard Draft

• Eventual Consistency and Compensation

1. Avoiding Transactions across Different Microservices

Let us take the example of the Twitter application. If Twitter maintains two different services for user profile information and tweets, and then if you want to show the last tweet date time of a user on the user profile screen, you have to store/update the tweet’s date and time (every single time any user tweets) in a users’ table. Here, we have to maintain distributed transactions across tweets and users’ information services.

Want to foray into microservices? Contact our expert developer team today!

Another method involves getting the last tweet’s date and time from the user while showing the user’s profile information by making a separate request to the ‘tweets’ microservice to get the latest tweet’s date and time. You can show this dynamically, and in this way, you can stop avoiding distributed transactions across multiple services without storing the tweet’s date and time in a user’s table.

This approach addresses transaction management at the design level.

2. Two-Phase Commit Protocol

This mechanism suits distributed systems. Microservices architecture inherently supports distributed systems, and the two-phase commit protocol (or 2PC) can be used as one of the approaches. The primary drivers in distributed transaction management systems are the message broker/transaction coordinator.

Read our blog : How to Build a Microservices Application

Any distributed transaction contains two steps one being the ‘Prepare’ phase and the second one being the ‘Commit or Rollback’ phase.

(a) Prepare Phase:

In the ‘Prepare’ phase, the transaction coordinator sends a prepare command at the beginning to each involved system. Each system then checks if it could commit the transaction. If they are ready for the commit, they will inform the message broker/transaction coordinator that they are ‘prepared’ for completing the transaction.

(b) Commit or Rollback phase:

In this phase, the transaction coordinator sends a ‘commit’ command to all the systems. If the transaction was completed successfully, the changes get committed. In case any of the systems does not answer the ‘prepare’ command or responds with a ‘failed’ response, the transaction coordinator sends an ‘abort’ command to all the systems. This rolls back all the changes that were recorded within the transaction. 

Read our blog : What Kind of Challenges Can Microservices Help You Overcome

The 2PC approach is a bit slow compared to the time for an operation on a single service because it has to coordinate the transactions between different services. Therefore, even if all the microservices are on the same network, the operation is likely to be slow. You have to be careful when implementing this for services that have a high demand. 

When implementing 2PC, you can follow one of the two standards described below.

• XA Standard

XA is a 2PC protocol natively supported by many databases and transaction monitors. It ensures data integrity by coordinating single transactions that access multiple relational databases. Any JTA-compliant application server supports the XA standard out of the box.

To make use of this specification, microservices have to be deployed in a single JTA platform, and this is not always possible in a microservices architecture environment.

• REST-AT Standard Draft

The REST-AT is another standard under development by RedHat and is still in the draft stage. However, this standard is supported by the WildFly application server currently out of the box. By using this standard, an application server acts as a transaction coordinator and also uses a specific REST API for handling distributed transactions. To access the local resources of any service in a distributed transaction, we still have to deploy these resources in a single JTA platform.

3. Eventual Consistency and Compensation

When handling distributed transactions in microservices, we should ensure that the system should end up consistent in the future. Though this model doesn’t compel the use of ACID transactions across services there should be some mechanism that ensures consistency.

Are microservices required for your organization? Consult with us today!

Every service involved in the transaction should provide information to the user on the status of the transaction. This should happen even if the next/consecutive service fails to respond and whenever services are up. It should ensure that all the scheduled transactions are complete and data in the system is consistent.

How SayOne Technologies can assist in Microservices Development

At Sayone, we design and implement microservices systems that do not have complex architectural layers, and this enables the services to deliver exceptionally fast performance. Moreover, we provide services that are significantly decoupled, allowing you to launch independent services and not end up with the usual inter-dependent microservices that work more or less like a monolith.

We design the microservices keeping in mind the margin required to allow for the transitioning into the new system of your organization’s legacy architecture as well as expanding into the cloud system. Our microservices comprise lightweight code and we provide competitive pricing options for our clients.

Our microservices are built according to the latest international security guidelines that ensure the complete safety of all the data. We also ensure that we deliver the services within stipulated deadlines and we always assure a quick turnaround time for our clients. Equipped with the best infrastructure and the latest tools and technologies, our expert developers will provide you with the best microservices that are easily scalable, enabling a good ROI in the shortest period.