# Enhancing Saga Pattern for Distributed Transactions within a Microservices Architecture
## 2 Literature Review
### Distributed Transactions in Microservices
#### 2.1.2 Saga Pattern  
To solve the problems with the 2 PC protocol, the saga pattern was introduced [3; 10] to organize the communication in a microservice architecture. In 1981, [PERSON] and [PERSON] introduced the SAGA project [11] which explored both the practical and the formal characteristics of computer-aided support for the software lifecycle in order to enable the design of a practical software development environment. In 1987, [PERSON] and [PERSON] [10] introduced the idea of utilizing the saga pattern for long lived-transactions by organizing them as a sequence of local transactions where each update of the database publishes an event or message to trigger the next local transaction. In other words, the saga has been introduced for updating data in multiple services in a microservices architecture without using distributed transactions. When one local transaction fails because of not complying with the business rules, a series of compensating transactions will be executed by saga to undo the changes that were made by the preceding local transactions.  
The authors in [10] described the saga as a sequence of operations that perform a specific unit of work and are generally interleaved with each other. Saga operations are allowed to be rolled back by a compensating action. Saga pattern ensures either the successful completion of all operations or running the corresponding compensation actions for all executed operations to rollback any work previously done. The idea of the saga pattern is rather than having long transactions which hold into locks, long transactions will be broken into a series of short transactions that commit in sequence [10].  
Generally, the choreography and the orchestration are the most two common approaches to coordinating the saga pattern. With choreography, sagas are coordinated with no centralized point of control where events are exchanged by participants. Domain events are published by local transactions to trigger local transactions in other services. On the other hand, the orchestration is another means to coordinate sagas where sagas will be coordinated with a centralized controller who tells saga participants what local transactions to execute based on the events. With the orchestrator, saga requests are executed, stored, and the task states are interpreted. With compensating transactions, the orchestrator handles failure recovery.  
Figure 1: Illustration of the two-phases commit protocol.  
The saga pattern was utilized by previous research. In general, implementing the saga pattern requires a creative way of thinking in order to coordinate transactions and maintain data consistency for a business process that spans multiple microservices. The design of a SAGA-based Pilot-Job was proposed in [12]. The design proposed by the research supports several types of applications to be usable over a broad range of infrastructures. In [13], a multi-agent-based framework in the microservices architecture, namely SagaMAS is proposed where the distributed transactions are coordinated by the framework simplifying the interactions among microservices and relieving developers from coordination tasks. In [14], the authors proposed a model-based approach for microservices and service integration through formal models using the UML and UML profiles. Previous research concluded that the saga architecture pattern is a useful means to implement distributed transactions in a microservice-based system. However, the saga pattern is ACD (atomicity, consistency, durability), not ACID (atomicity, consistency, isolation, durability) [3]. Read-isolation is missing in the saga pattern which in turn allows reading and writing data from an incomplete transaction [4] and in saga, the microservices commit changes to their local databases. The lack of read-isolation imposes a durability challenge. The saga implementation must include countermeasures to reduce anomalies.