Introduction to StackSaga

Stacksaga is a Saga Orchestration engine framework that built top of the spring boot framework. Orchestration engine helps you to manage your work flows to execute the primary executions and also the compensating executions in a very handy way to overcome the eventual consistency according to the saga design pattern. And also you can see here some of the major features that StackSaga provides.

  • Saga Orchestration engine for managing primary and compensating work flows.

  • Transaction Coordination

  • Idempotency (Ensures that repeating the same operation multiple times has the same effect as performing it once, which is crucial for reliability.)

  • Transactions Asynchronous-Retrying

  • Event sourcing (State Management)

  • Monitoring Distributed transaction tracing via the StackSaga Cloud-Window.

  • Concurrency Control

  • Managing the Dual consistency problem. And many more…

Why StackSaga?

If you implement the Saga orchestration design pattern in your system, you have to manually manage the work flows. It’s pretty tough to handle manually, like making sure the compensating actions are in the right order and also safely storing all the events for asynchronous retrying. To get the hang of the implementation, let’s check out an example.

Just imagine an E-Commerce application, and it should place an order. Even though this action is a single one from the clint perspective, if we are in microservices architecture, that single action consists of multiple sub operations like initialize the order, collecting user details, making pre-auth, updating stocks, making the real payment and so on. Doing these sub operations in sequence order is quite easy at first glance. But all the time these sub operations might not be executed smoothly.

  • Sometimes an error can occur while executing the last process or after some executions are done. Then, the compensating executions have to be executed in descending order (last-in, first-out (LIFO)).

  • Sometimes an error can occur due to resources unavailable like connection issues or the target service is unavailable temporarily. If there is this kind of situation in the Saga, it’s not recommended the starting compensating process. Because eventually, we will be able to execute the execution successfully after the resources are available. Here you have to implement a schedule mechanism to check the resource availability.

  • Even if you managed to handle all those challenges. Sometimes you may have to face dual-consistency problems as well.

Likewise, a lot of challenges will be covered by Stacksaga. As a developer, you only have to focus on the business case if you are using StackSaga on your system. The Stacksaga will take care of all other saga things and many challenges.

Stacksaga-Components

In the StackSaga ecosystem, few components are working together. It can be divided as below based on the usage.

Here you can see the relationship between them and how they are used in the StackSaga ecosystem.

stacksaga components.drawio

Stacksaga is configured based on the target service that you want to make the service as the Orchestration service. For instance if you want to configure stacksaga into the order service, you have to add the Orchestration service related components into the order service.

stacksaga-spring-boot-starter Dependency

stacksaga-spring-boot-starter is the core of the framework. it the stacksaga-spring-boot-starter is a java dependency that can be added into your project as a dependency.

<dependency>
  <groupId>org.stacksaga</groupId>
  <artifactId>stacksaga-spring-boot-starter</artifactId>
  <version>${org.stacksaga.version}</version>
</dependency>

stacksaga-db-support Dependency

StackSaga works with the help of the event-store. So it requires a one of database implementations for connecting with the target database. The database implementation is based on your target Orchestration service’s database. For instance, if you want to configure stacksaga into the order-service, and the Mysql database is used as the primary database in the order-service, you have to add the stacksaga database support mysql implementation called stacksaga-mysql-support dependency into the order service.

Currently, the following database implementations are available.

stacksaga-env-support Dependency

stacksaga-env-support Dependency provides the environment related geographical (region, zone, instance ID, etc.) data to the SEC. Based on where your applications are deployed the stacksaga-env-support should be changed. For instance, if you deploy your order-service application in the eureka environment(Eureka based service discovery and load balancing), you have to add the stacksaga-eureka-support dependency into the order service. And if you want to migrate your order-service application to the kubernetes environment, you can change the stacksaga-eureka-support dependency to the stacksaga-k8s-support dependency in the order service.

Currently, StackSaga supports for the following environments.

To manage the transaction retrying, you have to build the agent application for the target Orchestration service. To create an agent-service, you have to choose one of stacksaga-agent dependencies based on the target Orchestration service’s database. For instance, if you have configured StackSaga on the order-service with the stacksaga-mysql-support database, you have to create a stacksaga-agent application for the order-service by adding the stacksaga-mysql-agent dependency.

No need to worry about the environment that your agent-application is deployed. Because all the stacksaga-agent implementations supports for all the environments. You can adjust the agent-application by changing the profile to your target environment. For instance, if you want to deploy the agent-application in the kubernetes environment, you can mention the profile as k8s in the property file in your application.

The following stacksaga-agent dependencies are available for the specific databases.

StackSaga Cloud-Window

Stacksaga Cloud-Window is the platform that you can see the transaction tracing details of the transaction that you made in graphically. there is nothing to be implemented regarding this component. you can visit live.stacksaga.org and use it.

StackSaga in High-level

In the Introduction To Microservice., We got a clear idea of how microservice architecture works, and what are the challenges that we have to face when implementing the microservice in traditional way.

Here, we are going to see how the StackSaga works together with typical microservice architecture. It shows how StackSaga does impact on the default spring boot microservice architecture.

For your convenience, both Spring Microservice Architecture and Spring Microservice Architecture With StackSaga diagrams have been added here.

Spring Microservice Architecture

StackSaga High-level architecture

Spring Microservice Architecture With StackSaga

StackSaga High-level architecture

After adding StackSaga in to the microservice ecosystem, you can see there are some additional components in the high-level architecture diagram.

In the diagram, the Gray color components are related to the typical microservice architecture, and newly added StackSaga related components and connectivity-lines have been colored by Green color for your convenience.

  • You already know that the StackSaga framework provides the orchestration facility in the microservice architecture. So With the inclusion of StackSaga one of your services, the service become an orchestrator service. For instance, if we want to manage a sequence of transactions from the order-service, we should add StackSaga to the order-service only. So you are able to see in the diagram we have added StackSaga into the service-c. Due to adding stacksaga to the service-c, you can see that we have provided an extra database schema as the event-store. Because Stacksaga requires a database for managing the event-store.

    Even though the diagram shows event-store per service, It can be configured as a single event-store for all services if the application is currently not a large one. Read more.
    It is recommended to utilize one of the StackSaga database implementations that corresponds to the primary database of the specific service. This approach eliminates the need for configuring an additional separate database, thereby simplifying the overall architecture.
    As an example, If the order-service uses MYSQL database as the primary database, you can use the stacksaga-mysql-support implementation for the event-store.
There is no requirement to integrate StackSaga into all services within the ecosystem. It can be added selectively to the services that will benefit from its usage. For services that do not involve complex business domains, there is no necessity to incorporate StackSaga.

We had a quit a simple idea over this high-level overview. Let’s dive in to the deeper step by step to have a better understanding.