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. 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.)

  • Retrying transactions

  • Event sourcing (State Management)

  • Monitoring Distributed transaction tracing via the StackSaga admin dashboard.

  • Concurrency Control

  • Managing the Dual consistency problem. and many more..

StackSaga consists of two major components in high-level.

  1. StackSaga-Admin Dashboard

    StackSaga admin mainly provides the monitoring facilities of the transactions and manages the security.

  2. StackSaga Framework.

    • StackSaga Framework provides orchestration engine to manage your work flows to execute the primary executions and also the compensating executions.

Why StackSaga?

If you implement the Saga orchestration design pattern in your system, you have to manually manage the work flows. It’s quite difficult to manage manually. And specially managing the compensating in correct order is more difficult. And also you have to follow a way to store all the events safely for retrying the execution where the execution was stopped temporarily. To understand the implementation, let’s have a look at 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 you have to execute the compensating executions as the order of 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 in High-level

In the introduction section, 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

Microservice High Level Diagram

Spring Microservice Architecture With StackSaga

StackSaga High-level architecture

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

In the diagram, the Gray color components and lines are related to the typical microservice architecture, and additional stacksaga related components and lines have been colored by Green color.

Let’s have a look at all the components and how they are interacted with each other.

  1. At first glance, you can see a major difference in database architecture. The reason is StackSaga SEC uses event sourcing for managing your aggregator state for each executor. In brief, StackSaga internally uses a database to string your execution data as events. Therefore, If you are using StackSaga, you have to provide a database as 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 use one of the StackSaga database implementations that is equal to the primary database of the particular service. Because, you don’t need to configure another separate database and complicate the architecture.
    As an example, If the order-service uses MYSQL databases as the primary database, you can use the stacksaga-mysql-support implementation for the event-store.

  2. Next, Let’s have a look at StackSaga Admin. Admin provides a lot of facilities in the framework. Primarily feature is monitoring and tracking the transaction’s flow and trace. For monitoring your transactions, Admin should be able to retrieve the transaction data from each event-store. Internally, StackSaga client provides and exposes the endpoints for that.

According to the high-level architecture diagram and the brief explanation, you can identify one application and 4 libraries are involved for StackSaga.

No need to add StackSaga for all the services in the ecosystem. It can be added freely only to the services that you want to use. If There is no any complex business domain in some services, there is no point in adding StackSaga for that particular service and keep it as it is in the ecosystem. * StackSaga-Admin-Server Can be run as a standalone server.
StackSaga-Admin’s Database is used only for saving the User’s-Credentials and the Terminated Transactions' metadata. Other data that you can see in the StackSaga-Admin dashboard are obtained from each service’s event-store endpoints.

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.