Saga Pattern Technologies: A Criteria-based Evaluation

Karolin D

urr, Robin Lichtenth

aler

and Guido Wirtz

Distributed Systems Group, University of Bamberg, Germany

Keywords:

Microservices, Saga Pattern, Workﬂow Engine, Criteria–based.

Abstract:

One challenge in Microservices Architectures is coordinating business workﬂows between services, for which

the Saga pattern is frequently mentioned as a solution in the literature. This work presents a criteria cata-

log based on which existing technological solutions that help with Saga implementations can be qualitatively

evaluated to enable an informed decision between them. It considers criteria relevant for the Saga pattern, mi-

croservices characteristics, and for operating a system in production. We use it to evaluate four technological

solutions by implementing an exemplary use case. Due to their different origins, the technologies come with

varying strengths and weaknesses and as a result no solution is superior. The results can help developers decide

which technology to use and provide insights into what to consider when implementing the Saga pattern.

1 INTRODUCTION

The microservices architectural style, popularized

by companies like Netﬂix or Amazon, distributes

a system into small and autonomous services (Al-

shuqayran et al., 2016; Dragoni et al., 2017) commu-

nicating over the network, each modeled around one

business domain and exclusively owning its data stor-

age. Therefore, microservices can be independently

deployed, scaled, maintained, and evolved (Newman,

2015; Richardson, 2019). For business workﬂows in-

volving several microservices, however, coordination

between services is required to ensure consistency.

Using distributed transactions, for example with the

2–Phase Commit (2PC) protocol, would be a classical

approach (Al-Houmailya and Samaras, 2009; New-

man, 2019) in this regard. But with 2PC, the over-

all availability and scalability of a system is affected

(Newman, 2015; Richardson, 2019; Helland, 2016),

due to the strict locking requirements (Thomson et al.,

2012) combined with the comparatively slow and un-

reliable network–based communication.

The Saga pattern is therefore mentioned fre-

quently (Richardson, 2019; Newman, 2019;

Stefanko

et al., 2019; Garcia-Molina and Salem, 1987) as a

solution. It divides a transaction into multiple local

transactions so that locks for included resources do

not have to be held until full completion. For work-

ﬂows involving multiple services, the Saga pattern

https://orcid.org/0000-0002-9608-619X

https://orcid.org/0000-0002-0438-8482

therefore aligns better with the microservices charac-

teristic of autonomy (D

urr et al., 2021).

Nevertheless, the Saga pattern involves complex-

ity, because such independent local transactions need

to be coordinated and compensation must be possible

to take into account different failure scenarios. There-

fore, framework support can be helpful and suitable

technologies have emerged. This work investigates

different existing solutions by comparing their capa-

bilities based on a well–deﬁned criteria catalog. We

acknowledge that the Saga pattern is not suitable for

every use case, but this work does not provide an eval-

uation of when it ﬁts and when it does not. Instead, we

make the assumption that the Saga pattern has already

been identiﬁed as suitable for a use case at hand and a

technological solution for supporting the implementa-

tion needs to be chosen. Therefore, we also consider

aspects important when operating a system in produc-

tion, like monitoring or security. We summarize our

aim with the following research questions:

RQ1: What criteria can be used to evaluate and

compare existing technologies that support the

implementation of the Saga pattern?

RQ2: How do recent technological solutions that

support implementing the Saga pattern perform

concerning the deﬁned criteria?

In the following, we shortly describe the Saga pattern

in section 2, review similar evaluations in section 3,

and outline our approach in section 4. We evaluate the

technologies based on our criteria catalog in section 5,

discuss it in section 6 and conclude in section 7.

Dürr, K., Lichtenthäler, R. and Wirtz, G.

Saga Pattern Technologies: A Criteria-based Evaluation.

DOI: 10.5220/0010999400003200

In Proceedings of the 12th International Conference on Cloud Computing and Services Science (CLOSER 2022), pages 141-148

ISBN: 978-989-758-570-8; ISSN: 2184-5042

141

Abort Sagas

Start Cancel Flights

Start Sagas

Start Book Flights

Start Book Hotels

Flight Service

Saga

Execution

Coordinator

End Cancel Flights

Travel ServiceTravel Service

Begin Saga

Start Book Hotel

End Book Hotel

Start Book Flight

Abort Saga

End Saga

Saga Log

Start Cancel Flight

End Cancel Flight

Start Cancel Hotel

End Cancel Hotel

End Book Hotels

Start CancelHotels

End Cancel Hotels

Hotel ServiceHotel Service

request/ messages

writing to logs

Save Trip

Book Hotel

Cancel Hotel

Local transaction

MicroserviceMicroservice

Book Flight

Cancel Flight

Figure 1: Execution of a Saga’s failure scenario based on (D

urr et al., 2021) and

2 SAGA PATTERN

In 1987 (Garcia-Molina and Salem, 1987) introduced

the Saga pattern to manage long–lived transactions

(LLT). A Saga designs such a LLT as a sequence of

local transactions instead of a single ACID (Vossen,

2009) transaction as in the 2PC protocol.

Therefore, Sagas prevent the need for extended

locking of resources and allow updating data in mul-

tiple services without using distributed transactions

(Richardson, 2019). But it also means that an ap-

proach is needed to coordinate these independent ser-

vices, control each Saga’s progress, and resolve in-

consistencies eventually through compensation when

needed. Coordination of Sagas can be achieved ei-

ther through choreography (Lim

on et al., 2018) in

a decentralized way or through orchestration where

coordination is centralized in a so–called Saga Exe-

cution Coordinator (SEC), as proposed by (Garcia-

Molina and Salem, 1987). Because orchestration is

the approach originally proposed by (Garcia-Molina

and Salem, 1987) and it was found to be better suited

for complex business contexts by (Bruce and Pereira,

2018), in this paper we focus on the orchestration ap-

proach. As shown in ﬁg. 1, the SEC is the orchestra-

tor (Newman, 2019; Bruce and Pereira, 2018) and it is

in itself a stateless service that can be realized either

within an existing service or as a separate one. The

SEC relies on the Saga log, a distributed, persistent

log where the status of local transactions of all Saga

instances is tracked to control the progress and en-

able a continuation even if the SEC temporarily fails.

For further clariﬁcation, we now discuss the example

shown in ﬁg. 1 of a trip booking which can be con-

sidered as a LLT that includes booking a hotel and a

https://speakerdeck.com/caitiem20/applying-the-sag

a-pattern?slide=70

ﬂight. This example was also used by Catie McCaf-

frey

to introduce the Saga pattern in a microservices

architecture including a Travel Service that saves the

booking information and initiates the execution, a Ho-

tel Service responsible for hotel bookings and a Flight

Service for ﬂight bookings.

Here, the SEC is either part of the Travel Service

or an individual service and relies on the services’ in-

terfaces to execute Sagas. Upon a trip request, the

Travel Service initiates the Saga instance and exe-

cutes the Save Trip transaction locally. Then, the SEC

triggers the hotel booking and waits for a response.

Booking a hotel, however, is completely in the re-

sponsibility of the Hotel Service which controls its

own state and has to ensure consistency through local

transactions. Therefore, the SEC relies on the pro-

vided functionality without knowing about details of

such local transactions. If booking a hotel succeeds,

the SEC is informed and triggers the next service to

proceed (Richardson, 2019; Lim

on et al., 2018) until

all transactions are completed and thereby the Saga

itself is completed. However, in case a local trans-

action fails like the ﬂight booking in ﬁg. 1, all pre-

viously done changes have to be compensated. The

most commonly used strategy uses so–called com-

pensating transactions (Richardson, 2019; Garcia-

Molina and Salem, 1987). A compensating transac-

tion rolls the previous changes back, either entirely or

at least semantically (Newman, 2019; Garcia-Molina

and Salem, 1987). Each service participating in a

Saga has to guarantee the possibility to compensate

state changes introduced by previous transactions.

This might also include additional compensations ex-

ternal to the Saga in focus but required due to such

state changes. However, this remains the responsibil-

ity of the service currently providing compensation.

https://www.youtube.com/watch?v=xDuwrtwYHu8

CLOSER 2022 - 12th International Conference on Cloud Computing and Services Science

142

In our example, this means that the Hotel Service has

to ensure the compensation of the hotel booking if the

ﬂight booking fails and therefore has to be canceled.

3 RELATED WORK

Some previous studies have also assessed existing

technologies with regards to the Saga pattern. The

study by (

Stefanko et al., 2019) analyzed four dif-

ferent Java–based application frameworks: Axon

Eventuate Event Sourcing

and, like us, Eventu-

ate Tram

and MicroProﬁle Long–Running Actions

(LRA)

, but based on the Narayana

implementa-

tion. Their evaluation focused on assessing the frame-

works’ support for the Saga pattern, its implemen-

tation complexity, and a performance analysis in-

vestigating the system’s behavior under large load

(

Stefanko et al., 2019). However, they do not specify

their used quality criteria in detail. As a further con-

tribution, they reported discovered problems for each

framework. (D

urr et al., 2021) used a solely qual-

itative analysis to compare two technological solu-

tions: Eventuate Tram and the workﬂow orchestration

engine Netﬂix Conductor

. They consider general

Saga execution characteristics, as well as microser-

vices characteristics and challenges for their evalua-

tion criteria, but do not describe their criteria in detail.

Our work therefore extends their work by consider-

ing additional technological solutions as well as an

extended criteria catalog. Besides these two studies,

(Fugaro and Vocale, 2019) shortly describe different

Saga implementation possibilities in their book and

brieﬂy address some of the challenges of each frame-

work, but without an evaluation according to speciﬁc

criteria. In this context, they mention Axon, Eventu-

ate Event Sourcing, and Eventuate Tram, but focus on

an implementation proposal using MicroProﬁle LRA.

4 METHODOLOGY

While considering the aforementioned evaluations

urr et al., 2021; Fugaro and Vocale, 2019;

Stefanko

et al., 2019) in combination with a literature review,

we create a criteria catalog that can be used for a

https://docs.axoniq.io/reference-guide/axon-framewor

k/sagas

https://eventuate.io/usingeventuate.html

https://eventuate.io/abouteventuatetram.html

https://microproﬁle.io/project/eclipse/microprofile-lra

https://narayana.io/lra/

https://netflix.github.io/conductor/

technological evaluation. As additional resources we

used further literature (Estdale and Georgiadou, 2018;

Gaffney, 1981; Cruz et al., 2006; Conﬁno and La-

plante, 2010) as well as the ISO/IEC 25010 Quality

Models

to develop a comprehensive criteria catalog.

The catalog realizes a qualitative evaluation since it

does not include quantitative aspects like system load

or performance. We then use this catalog to evaluate

an example Saga pattern implementation using four

different technological solutions. As many criteria of

urr et al., 2021) are adopted, reﬁned but also ex-

tended, their analyzed solutions Eventuate Tram and

Netﬂix Conductor are re–evaluated. While Eventu-

ate Tram is a framework speciﬁcally designed for the

Saga pattern, Netﬂix Conductor represents a work-

ﬂow orchestration engine designed for distributed

workﬂows in general. As a third solution, we consider

MicroProﬁle LRA (backed by the Eclipse Founda-

tion) since it represents a very recent solution explic-

itly designed for LRA in microservices, so also Sagas.

The fourth and last evaluated solution is the work-

ﬂow engine Camunda

that can execute processes

which are deﬁned using Business Process Modeling

and Notation (BPMN). Since the BPMN language

itself provides the option of deﬁning compensation

events for tasks, R

ucker (R

ucker, 2021) suggested us-

ing a BPMN–based workﬂow engine like Camunda to

realize the Saga pattern. In addition, BPMN is an es-

tablished standard, and Camunda was not considered

in similar evaluations yet.

For Eventuate Tram (v0.14.0), Netﬂix Conductor

(v2.30.3) and Camunda (v7.15.0), we implemented

the sample application’s microservices as Spring

services. In contrast, our MicroProﬁle LRA (v1.0) re-

alization, implemented those using the MicroProﬁle

runtime provided by OpenLiberty

. More informa-

tion concerning the realization can be found online

5 RESULTS

To perform a structured evaluation of different tech-

nological solutions for implementing the Saga pat-

tern, clearly described and relevant criteria are

needed. In the following we shortly describe the crite-

ria catalog that we have developed and the evaluation

of the technologies based on this catalog.

https://iso25000.com/index.php/en/iso-25000-standa

rds/iso-25010

https://camunda.com/

https://spring.io/

https://openliberty.io/docs/21.0.0.6/microprofile.html

https://github.com/KarolinDuerr/BA-SagaPattern

Saga Pattern Technologies: A Criteria-based Evaluation

143

5.1 Criteria Catalog

Our criteria catalog considers several areas of inter-

est related to characteristics of microservices and the

Saga pattern as well as some quality attributes of the

ISO/IEC 25010 standard. The focus is on how the

Saga pattern can be implemented with the respective

technologies and what they offer in addition for oper-

ating and maintaining a system based on the Saga pat-

tern in production. We have therefore adopted and in

some cases reﬁned the criteria for general Saga char-

acteristics, monitoring, expandability, and fault

tolerance from (D

urr et al., 2021). In addition, orga-

nized by the quality attributes of the ISO/IEC 25010

standard, we have derived criteria considering the ar-

eas of security, testability, and portability. And ﬁ-

nally, we adopted some open–source characteristics

from (Conﬁno and Laplante, 2010), because they can

also be relevant aspects to consider when selecting a

technology. Although some characteristics have to be

treated with caution as they may be subject to differ-

ent interpretations, like repository stars, or since no

generally accepted metrics exist, for example regard-

ing documentation (Conﬁno and Laplante, 2010). We

described all criteria in more detail in order to have

a comprehensive and understandable criteria catalog

that could also be applied to additional technologies.

However, we cannot report the complete catalog due

to space limitations here, but provide it online

. Fur-

thermore, the different criteria are also presented in

the following technological evaluation.

5.2 Technological Evaluation

In the following, we use all criteria from our catalog

to evaluate the implementations

based on the four

technologies: the Eventuate Tram Saga framework,

Netﬂix Conductor, Camunda, and MicroProﬁle LRA.

Table 1 and table 2 summarize our results, of which

some originate from the previous work by (D

urr et al.,

2021) on Eventuate Tram and Netﬂix Conductor.

Considering general Saga characteristics, Con-

ductor and Camunda offer a bit more ﬂexibil-

ity, because Sagas can be deﬁned in a language–

independent way and for the communication between

participants different options such as HTTP requests

or Kafka

messages are available. Instead, Even-

tuate provides a Java–based DSL and MicroProﬁle

LRA requires Java Annotations to deﬁne Sagas based

on JAX–RS resources. The communication between

https://karolinduerr.github.io/BA-SagaPattern/Criteria

Catalog/

https://github.com/KarolinDuerr/BA-SagaPattern

https://kafka.apache.org/

participants is prescribed (Kafka messages for Even-

tuate and HTTP requests for MicroProﬁle LRA).

Only Eventuate and Camunda allow to directly link

the compensating transactions to transactions, which

means only executed ones will be compensated (D

urr

et al., 2021). With MicroProﬁle LRA, a correspond-

ing compensating transaction needs to be deﬁned in

the same Java class to achieve this effect. Whereas

for Conductor, per workﬂow, which represents a Saga

as a collection of tasks, only one failure workﬂow can

be speciﬁed which includes all compensating trans-

actions. In case of an abort, the failure workﬂow is

started and thus also unnecessary compensating trans-

actions might be executed (D

urr et al., 2021). Con-

ductor and Camunda rely on a central engine to or-

chestrate the Saga execution which in the case of Ca-

munda can also be integrated with a service, e.g. the

TravelService. The TravelService only starts a Saga

execution then. With Eventuate and MicroProﬁle, the

TravelService has the role of the orchestrator, but it

relies on Eventuate’s CDC service and the MicroPro-

ﬁle Coordinator respectively. Furthermore, Eventu-

ate limits the Saga process execution to a strictly se-

quential one (D

urr et al., 2021) whereas the others

allow for parallel execution of speciﬁed transactions.

In the case of MicroProﬁle LRA, this is possible be-

cause it is the developer’s responsibility to implement

the Saga sequence. Triggering the compensation pro-

cess for a Saga externally is possible with all tech-

nologies, except Eventuate, using the provided API.

Though with Eventuate Tram participants can be con-

nected directly (D

urr et al., 2021) enabling also an

event–based choreography approach.

Our results for monitoring aspects partly stem

from the previous evaluation by (D

urr et al., 2021).

To retrieve runtime information, Conductor and Ca-

munda provide a UI with several functionalities like

visualizing current workﬂows. In contrast, with Even-

tuate all transactions and messages can only be ac-

cessed directly via the database, which could however

be used to realize a custom visualization tool. Also

MicroProﬁle LRA only provides a small set of run-

time insights (LRA status: active/failed/closed) via

the coordinator API. Metrics like average execution

times or the number of failed Sagas can be collected

from an endpoint for all technologies. Additionally,

Eventuate Tram and MicroProﬁle LRA allow for easy

activation of distributed tracing, using for example

Zipkin or Jaeger

. Furthermore, all technologies pro-

vide sufﬁcient logging. For the expandability crite-

ria subset, we performed an extension of the imple-

mentations and results are again derived from (D

urr

et al., 2021) where suitable. Expandability is facili-

https://www.jaegertracing.io/

CLOSER 2022 - 12th International Conference on Cloud Computing and Services Science

144

Table 1: Evaluation overview – Part 1.

Criterion Eventuate Tram Netﬂix Conductor Camunda MicroProﬁle LRA

General Saga Characteristics

Saga deﬁnition Eventuate DSL

JSON /

provided clients

Modeler/

XML / Java DSL

Annotations

Orchestrating services

CDC Service,

TravelService

Conductor server

Camunda Engine

in TravelService

MicroProﬁle Coordinator,

TravelService

Specifying compensating

transactions

3 3 3 3

Compensation transaction

allocation

speciﬁc transaction

entire workﬂow

speciﬁc transaction

JAX-RS

resource class

Parallel transaction execution 7 3 3 developer’s responsibility

Parallel execution conﬁgurable 7 3 3 developer’s responsibility

Participant communication

selectable

7 3 3 7

External compensation trigger not directly via API via API via API

Choreographed Sagas 3 7 7 7

Monitoring

Runtime state of Sagas

via database UI visualization

UI visualization,

database

partly via

coordinator API

Orchestrator metrics

from CDC service

from Conductor

server

from embedded

Process Engine

from embedded Coor-

dinator, TravelService

Tracing Zipkin integration

not directly

supported

not directly

supported

Zipkin & Jaeger

integration

Logging microservices logs

Conductor server

logs

microservices logs microservices logs

Expandability

Terminating/Pausing

running Sagas

not directly via API / UI via API / UI via API

Versioning Sagas 7 3 3 7

Built–in language support Java Java, Python Java Java

Any language for orchestrator 7 3 3 7

Any language for participant 3 3 3 7

Fault Tolerance

Execution timeouts 7 enforced enforced 3

Reaction to participant fault unsubscribe retry retry

developer’s responsibility

& compensation

Saga continuation trigger

after orchestrator crash

new Saga instance

restart of

Conductor server

restart of

TravelService

(developer’s responsibility)

New Sagas while orchestrator

unavailable

3 only with buffering 7 7

Independent compensating

transactions

3 7 3 3

Orchestrator reaction to

duplicate messages

detect & ignore detect & ignore

log exception

& ignore

developer’s responsibility,

detect & ignore

Orchestrator reaction to

old messages

detect & ignore detect & ignore

log exception

& ignore

developer’s responsibility,

detect & ignore

High availability through replication through replication through replication –

Saga Pattern Technologies: A Criteria-based Evaluation

145

Table 2: Evaluation overview – Part 2.

Criterion Eventuate Tram Netﬂix Conductor Camunda MicroProﬁle LRA

Security

Encrypted Communication

3 3 3 3

Authentication Support

7 7 3 MicroProﬁle JWT

Authorization Support

7 7 3 MicroProﬁle JWT

Testability

In–house test framework 3 7 3 7

Unit test Saga deﬁnition 3 7 3 successful Saga

Unit test Saga participant 3 3 3 3

Saga integration test

3 3 3 3

Portability

Containerization

Docker Hub image

Dockerﬁle & community

Docker Hub image

Docker Hub image Docker Hub image

Kubernetes examples 7 Kubernetes examples Kubernetes examples

Cloud Provider 7 7 Camunda Cloud several guides

OSS Characteristics

Provider Eventuate Netﬂix Camunda Eclipse

License Type Apache Licence 2.0 Apache Licence 2.0 Apache Licence 2.0 Apache Licence 2.0

Repository Stars

***

781 3664 2350 71

Fork Count

***

180 approx. 1200 approx. 1000 24

Contributor Count

***

2 161 175 18

Support

Issue tracking

Discussion forum

Enterprise support

Issue tracking

Discussion forum

Issue tracking

Discussion forum

Enterprise support

Issue tracking

Discussion forum

Documentation 3 3 3 3

Not implemented by the prototype

Depends on chosen MicroProﬁle runtime, here: OpenLiberty

***

Numbers speciﬁc for respective Github repository, as of 2021-11-30

tated the most by Conductor and Camunda, as both

allow to pause or terminate currently running Sagas

either via their API or UI and they support version-

ing Sagas so that Sagas of a new version can start

while a previous version still runs. Also, considering

the usage of different programming languages, Con-

ductor and Camunda do allow both the orchestrator

and the participants to be written in almost any lan-

guage, because the deﬁnition of Sagas is language–

independent. MicroProﬁle LRA is restricted, because

the MicroProﬁle speciﬁcation is explicitly for Java–

based microservices, while Eventuate prescribes Java

only for the orchestrator so that participants could be

written in any language. This is possible, although

built–in support is only provided for Java, which is

similar to the others, except for Conductor which also

offers a Python client.

Regarding aspects of fault tolerance to handle

distributed systems challenges, we found that Con-

ductor, Camunda, and Eventuate retry communica-

tions in case of participant crashes. However, Even-

tuate unsubscribes participants responding with a fail-

ure and they are re–registered only after a restart (D

urr

et al., 2021). MicroProﬁle LRA itself provides no

handling, but it can be combined with MicroProﬁle

Fault Tolerance

. Execution timeouts are enforced

by Conductor and Camunda and can be deﬁned with

MicroProﬁle LRA, so that compensation is triggered

if the timeout is reached, whereas Eventuate might

wait indeﬁnitely (D

urr et al., 2021). All technolo-

gies, except Conductor, can tolerate failures during

compensation for participants where no compensation

is necessary, because of their independent speciﬁca-

tion. Orchestrator crashes are tolerated by persisting

the Saga state, only MicroProﬁle LRA leaves this to

the developer. However, Eventuate needs an external

trigger like a new Saga start to continue (D

urr et al.,

https://github.com/eclipse/microprofile-fault-toleranc

CLOSER 2022 - 12th International Conference on Cloud Computing and Services Science

146

2021), while Conductor and Camunda continue after

a restart. Starting new Sagas while the orchestrator

is unavailable is only possible when a separate ser-

vice is responsible for the Saga start as in the case of

Eventuate (D

urr et al., 2021) or when the orchestrator

would be a service separate from the TravelService.

Otherwise, buffering requests is another option. All

technologies, except MicroProﬁle LRA, detect and

ignore duplicated or old messages by default. Fi-

nally, all technologies can be set up to be highly avail-

able by replicating their respective orchestrators, ex-

cept for MicroProﬁle LRA where the chosen runtime,

OpenLiberty, does not include explicit information

on replication. Regarding security criteria, all tech-

nologies support encrypted communication, although

partly not built–in. Extensive authentication and au-

thorization support, however, is only provided by Ca-

munda for example by deﬁning user groups. Mi-

croProﬁle LRA can be combined with MicroProﬁle

JWT Auth

to include authentication and authoriza-

tion. Because proper Saga implementations should

also include tests (Richardson, 2019), the technolo-

gies should ideally facilitate testability. Of the four

evaluated technologies, only Eventuate and Camunda

provide in–house test frameworks which also allow

testing the Saga deﬁnition in isolation. With Micro-

Proﬁle LRA, currently only the success case of a Saga

execution can be tested due to the annotation–based

compensation mechanism. Nevertheless, testing Saga

participants in isolation and writing integration tests

is possible with all four technologies. To support

portability, technologies should be deployable on

different platforms. All support containerization via

Docker and Kubernetes, although for Conductor only

a community image is available and no examples for

Kubernetes are given. In the case of MicroProﬁle

LRA, deployability depends on the chosen runtime,

in our case OpenLiberty. Deployment instructions for

speciﬁc cloud providers are merely available for Ca-

munda with Camunda Cloud

and MicroProﬁle LRA

which provides several guides

. Finally, considering

OSS characteristics, it can be stated that Conductor

and Camunda show a higher community interaction,

which might be due to the popularity of the providers

behind them. Instead, Eventuate has a very speciﬁc

focus and MicroProﬁle LRA is very recent (its ﬁrst re-

lease was in May 2021). Support options are equally

well, only Eventuate and Camunda also offer a paid

enterprise version with additional support. Again, for

MicroProﬁle LRA, the support depends on the chosen

runtime. Each technology also maintains detailed and

https://github.com/eclipse/microprofile-jwt-auth

https://camunda.com/products/cloud/

https://openliberty.io/guides/#cloud deployment

clear documentation including examples. In terms of

license type, all solutions have opted for the Apache

Licence 2.0 which ranks among the most permissive

licenses (Conﬁno and Laplante, 2010).

6 DISCUSSION AND FUTURE

WORK

With our criteria catalog in Section 5.1 we provide

an answer to RQ1. It covers a comprehensive set

of criteria which can be used to evaluate technolog-

ical solutions for implementing the Saga pattern. The

focus is on how well an implementation of the Saga

pattern is supported, also considering operational as-

pects, like monitoring or expandability. Except for the

criteria Saga deﬁnition and Specifying compensating

transactions which are basic requirements, the impor-

tance of the criteria depends on the speciﬁc context in

which a system is implemented and no general order

of importance for the criteria can be established. For

example, Authentication Support might not be that

important in a context where all services run in an

isolated network while Containerization is important

for ﬂexibility regarding the execution environment.

To use the catalog for an evaluation of a technol-

ogy, in principle, the documentation of a technology

is sufﬁcient if it provides detailed enough informa-

tion. But to have reliable results, an actual imple-

mentation using the technology is needed, especially

considering the criteria for Fault Tolerance. Our an-

swer to RQ2 is therefore based on the implementa-

tions and presented in Section 5.2. While, in sum-

mary, all four evaluated technologies allow robust im-

plementations of the Saga pattern, we identiﬁed the

following differences. Since Netﬂix Conductor is not

speciﬁcally designed for Sagas, it does not represent

the respective characteristics as clearly as the other

frameworks. However, it allows for more conﬁgura-

tion options like the chosen communication mecha-

nism. Camunda is somehow similar but represents the

Saga characteristics better due to the usage of BPMN

which provides suitable entities (e.g., service tasks or

compensation events) to design Sagas. While Eventu-

ate Tram and MicroProﬁle LRA are actually designed

for the Saga pattern, they also come with more lim-

itations concerning conﬁgurability. Nevertheless, a

choreographed approach is only supported by Even-

tuate Tram. Good Saga testability support is solely

provided by Camunda and Eventuate Tram, as they al-

low running tests in isolation. When extending an ex-

isting system, Netﬂix Conductor and Camunda allow

for greater ﬂexibility, among other things, through the

possibility of versioning. Additionally, Conductor’s

Saga Pattern Technologies: A Criteria-based Evaluation

147

and Camunda’s UI are beneﬁcial tools when monitor-

ing a system. On the other hand, the ability to ac-

tivate tracing without additional implementation ef-

fort is only provided by Eventuate Tram and Micro-

Proﬁle LRA. All four technologies offer some porta-

bility support. However, only Camunda and Micro-

Proﬁle LRA (depending on the runtime) provide spe-

ciﬁc cloud provider support. Security–related features

are currently only available with Camunda. For Mi-

croProﬁle LRA, additional MicroProﬁle extensions

could be used to realize security aspects. All tech-

nologies consider fault tolerance, also with some con-

ﬁguration options. Only MicroProﬁle LRA leaves

some aspects to the developer’s responsibility. Con-

cerning OSS characteristics, documentation and sup-

port exist for all technologies.

Because the importance of the considered criteria

differs depending on the context and the evaluated so-

lutions differ in how they support the criteria, it is not

possible to make a statement about whether one so-

lution is better than another. Nevertheless, our eval-

uation can be used to make an informed decision on

which solution ﬁts which context. In future work, ad-

ditional solutions can be evaluated or the catalog can

be extended with quantitative measures, for example

considering performance or resource utilisation.

7 CONCLUSION

Because implementing the Saga pattern involves con-

siderable complexity, technologies supporting it have

emerged from which a suitable one can be chosen.

To make such a choice in an informed way, our work

presents a criteria catalog for evaluating Saga pattern

implementation technologies and applies it to four ex-

isting solutions. Based on our ﬁndings, the considered

technologies differ according to how they support the

criteria and no technology is superior to the others.

Our evaluation can therefore be used to select a suit-

able technology for a speciﬁc context in which the

Saga pattern should be implemented.

REFERENCES

Al-Houmailya, Y. J. and Samaras, G. (2009). Two-Phase

Commit. In Encyclopedia of Database Systems, pages

3204–3209. Springer US.

Alshuqayran, N., Ali, N., and Evans, R. (2016). A Sys-

tematic Mapping Study in Microservice Architecture.

In 9th International Conference on Service-Oriented

Computing and Applications (SOCA), pages 44–51.

IEEE.

Bruce, M. and Pereira, P. A. (2018). Microservices in Ac-

tion. Manning Publ., 1st edition.

Conﬁno, J. P. and Laplante, P. A. (2010). An Open Source

Software Evaluation Model. Int. J. Strateg. Inf. Tech-

nol. Appl., 1(1):60–77.

Cruz, D., Wieland, T., and Ziegler, A. (2006). Evalua-

tion Criteria for Free/Open Source Software Products

Based on Project Analysis. Software Process: Im-

provement and Practice, 11(2):107–122.

Dragoni, N., Giallorenzo, S., Lluch-Lafuente, A., Maz-

zara, M., Montesi, F., Mustaﬁn, R., and Saﬁna, L.

(2017). Microservices: Yesterday, Today, and Tomor-

row. In Present and Ulterior Software Engineering,

pages 195–216. Springer.

urr, K., Lichtenth

aler, R., and Wirtz, G. (2021). An

Evaluation of Saga Pattern Implementation Technolo-

gies. In 13th European Workshop on Services and

their Composition (ZEUS), volume 2839, pages 74–

82. CEUR-WS.org.

Estdale, J. and Georgiadou, E. (2018). Applying the

ISO/IEC 25010 Quality Models to Software Product.

In Systems, Software and Services Process Improve-

ment - 25th European Conference (EuroSPI), volume

896 of CCIS, pages 492–503. Springer.

Fugaro, L. and Vocale, M. (2019). Hands-On Cloud-Native

Microservices With Jakarta EE. Packt Publ., 1st edi-

tion.

Gaffney, J. E. (1981). Metrics in Software Quality Assur-

ance. In Proceedings of the ACM 1981 Annual Con-

ference, pages 126–130. ACM.

Garcia-Molina, H. and Salem, K. (1987). Sagas. In Pro-

ceedings of the 1987 SIGMOD International Confer-

ence on Management of Data, volume 16, pages 249–

259. ACM Press.

Helland, P. (2016). Life Beyond Distributed Transactions:

An Apostate’s Opinion. ACM Queue, 14(5):69–98.

Lim

on, X., Guerra-Hern

andez, A., S

anchez-Garc

ıa, A. J.,

and Arriaga, J. C. P. (2018). SagaMAS: A Software

Framework for Distributed Transactions in the Mi-

croservice Architecture. In 6th International Confer-

ence in Software Engineering Research and Innova-

tion (CONISOFT), pages 50–58. IEEE.

Newman, S. (2015). Building Microservices - Designing

Fine-Grained Systems. O’Reilly Media, 1st edition.

Newman, S. (2019). Monolith to Microservices: Evolution-

ary Patterns to Transform Your Monolith. O’Reilly

Media, 1st edition.

ucker, B. (2021). Practical Process Automation. O’Reilly

Media, 1st edition.

Richardson, C. (2019). Microservices Patterns. Manning

Publ., 1st edition.

Thomson, A., Diamond, T., Weng, S.-C., Ren, K., Shao,

P., and Abadi, D. J. (2012). Calvin: Fast Distributed

Transactions for Partitioned Database Systems. In

SIGMOD International Conference on Management

of Data, pages 1–12. ACM.

Vossen, G. (2009). ACID Properties. In Encyclopedia of

Database Systems, pages 19–21. Springer US.

Stefanko, M., Chaloupka, O., and Rossi, B. (2019). The

Saga Pattern in a Reactive Microservices Environ-

ment. In Proceedings of the 14th International Con-

ference on Software Technologies (ICSOFT), pages

483–490. SciTePress.

CLOSER 2022 - 12th International Conference on Cloud Computing and Services Science

148