The benefits related to microservice architectures are there for all to see, from the reduction of the time to market, to the simpler management of the source life cycle, to the punctual management of resources, according to the actual workload.

However, at the end of every discussion on microservices, before proceeding to the design of the application architecture, a question always comes up—how are the transactions managed within microservices?

Distributed system interactions can be complex for many reasons, some of which are as follows:

• A microservices architecture involves many parties, realized using different technologies that adhere to different specifications
• A business function can span many different organizations that can have different service-level agreements, and, for this reason, can be implemented with various strategies
• A business function potentially lasting for hours or days, a logic that hardly reconciles with scalability—indeed it's very difficult to scale an application that has a logic based on the lock, performed by a transaction, which makes the system irresponsive for a long time

To preserve its high scalability feature, a microservice may not be able to lock resources indefinitely.

A business function can be composed of numerous microservices, each of which is responsible for managing a specific data domain. In complex cases, in which a business feature to be implemented needs to implement more steps, it may be required to undo only a subset of work which was previously done.

However, the concepts expressed in the previous sections (relating to the ACID properties of transactions) have always worked correctly in previous architectural models, including that of SOA; so, why give those up? And, if we are forced to do so, how can the data's integrity be managed?

It is not easy to use the JTA (and, especially, the XA) in microservices architecture. The reasons lie in the nature of ACID transactions, which implicitly assume the following:

• Have a closely coupled environments where all entities involved in a transaction span a LAN
• Have activities with a short execution time that must be able to work properly when the resources are locked for periods of time

Microservices are based on diametrically opposed concepts, such as loosely coupled environments and long-duration activities. Furthermore, microservices are distributed systems, and communication over the network brings a few complications, such as network failures and communication performance issues due to network overhead. Failure and performance are two aspects in which transactions can have a high incidence rate.

In 1997, James Gosling, the father of Java, extended a draft created by Peter Deutsch, which stated incorrect assumptions that were commonly made about distributed systems.

These assumptions are known as The eight fallacies of distributed computing, and they are as follows:

• The network is reliable
• The latency is zero
• The bandwidth is infinite
• The network is secure
• The topology doesn't change
• There is one administrator
• The transport cost is zero
• The network is homogeneous

All of these factors have important implications in the management of transactions, as was already discussed in the Consensus protocols section.

The microservices architecture tackles this series of problems with one word: relaxation.

It proposes a less rigid approach regarding the ACID properties, as follows:

• Atomicity: The microservices architecture approach prefers to undo a portion of work rather than cancel all of the work. For example, imagine you're booking a holiday—I'm sure that you prefer to buy an airline ticket, maybe when it has a very good price, even without travel insurance, rather than failing to book the trip and, consequently, stay at home only because the insurance service is temporarily unavailable. This model is similar to that of nested transactions where the work performed within their scope is provisional. A nested transaction represents a problem from a JTA point of view; support for nested transactions is not required, as declared in the specifications, and XAResource does not support nested transactions. So, it's very difficult to implement this concept in the Java EE/Jakarta EE environment. In the end, the mantra must be that failure does not affect enclosing the transaction.
• Consistency: ACID transactions, and the two phase commit protocol, are based on strong global consistency. All participants stay in the lock step and they must retrieve the same transaction outcome. But this approach doesn't scale, and weak consistency replication protocols were developed for large scales. A weak or relaxed consistency is the approach proposed by microservice architectures. This model is known as eventual consistency, also known as optimistic replication—its main concept is that the system guarantees that, if no new updates are performed to the requested object, all of the data reads will return the last updated value. With this approach, the system does not provide any guarantees about the consistency of data for a limited period, also defined as inconsistency window. Microservices must manage the eventual consistency model to avoid to make decisions based on inconsistent information. Distributed systems, such as microservices, are unable to guarantee both strong consistency and high availability at the same time. For this reason,distributed business applications are often chosen to tolerate temporary data inconsistencies in favor of promoting availability. This approach is also classified as Basically Available, Soft state, Eventual consistency (BASE) in contrast to traditional ACID semantic.
• Isolation: In this case, the microservice approach is to delegate the isolation of the resources to a service provider. It could decide to commit early and perform a compensation actions later. The important thing is that the undo operation, which is needed for the system to come back to its original state, must be always available.