The basic purpose of a microservices architecture is to provide decoupled and independent components that encourage agility, adaptability, and a faster time to market for your applications. Each microservice component has its own data persistence layer as a result of decoupling. Business transactions in a distributed architecture might span numerous microservices. Because these microservices cannot employ single atomicity, consistency, isolation, and durability (ACID) transaction, partial transactions may result. In this instance, some control mechanism is required to reverse already executed transactions. Typically, the distributed saga pattern is employed for this purpose. When a transaction needs to be orchestrated across several databases, you can utilize AWS Step Functions to do so.
How Is the SAGA Pattern A Failure Management Pattern?
The saga pattern is a failure management pattern that aids in the establishment of consistency in distributed systems and organizes operations across various microservices to ensure data consistency. When using the saga design, each service that completes a transaction broadcasts an event that causes succeeding services to complete the next transaction in the chain. This process is repeated until the last transaction in the chain is completed. If a business transaction fails, saga will arrange a sequence of compensatory transactions to reverse the changes produced by the previous transactions.
This pattern shows how to use the AWS Cloud Development Kit (AWS CDK) and serverless technologies such as AWS Step Functions, AWS Lambda, and Amazon DynamoDB to automate the setup and deployment of an example application (which handles trip reservations). To construct a saga execution coordinator, the sample application additionally makes use of Amazon API Gateway and Amazon Simple Notification Service (Amazon SNS).
Distributed systems are inherently complicated. In this article, I have mentioned why AWS Step Functions (SF) are a viable solution and show how to use them to construct our sample domain. So let’s start by delving into the inner workings of an organized Saga.
What are Orchestrated Saga Building Blocks?
The SEC (Saga Execution Coordinator) is at the core of the orchestrated Saga. As the name indicates it is in charge of coordinating the execution of the operations to achieve the intended functionality. An SEC keeps track of the tasks to be carried out. Their order, and what measures should be taken in the event of a failure. This is a state machine pattern that may be expressed as an acyclic directed graph (ADG).
The SEC saves the current state and utilizes it to choose what to do next when it receives responses to instructions it delivers. In the above para, the SEC requests the system to allocate the item, maintains note of this, and determines whether I send the item or cancel the order based on the answer. Because of its critical significance, every SEC solution should be:
1. Scalable
You should be able to begin as many SEC executions as necessary to meet the demands of the firm.
2. Resilient
Issues will arise, and the compute node in charge of the SEC may need to be rebooted (ex. hardware problems, maintenance). You want to be able to pick up where you left off without any problems.
3. Versioned
A Saga is a visual depiction of a business process that evolves over time. It is critical that the SEC adheres to the version of the procedure that it began executing.
4. Multiplexed
Because there will be numerous concurrent executions of the same or distinct processes, the system must be able to route answers to previously received instructions to the correct SEC instance.
5. Unaware of business logic
The SEC is responsible for the coordination and should not include domain logic, which should still be located at the services. Though required none of the above requirements generate immediate business benefits. Developing and maintaining them can take a significant amount of time that might be spent on providing new customer-facing services.
When this occurs, I normally advise looking for a better solution in the form of a non-intrusive framework or managed service that you may use. Managed services not only give you the inner workings of an SEC, but also the infrastructure required to run your application.
AWS Step Function Fundamentals
Before we create our Saga, let’s go through the fundamentals of AWS Step Functions.
The AWS Step Function, at its essence, allows you to organize actions that must be completed. Begin by establishing the workflow that will be used. Any process has two main components:
1. States
Each state reflects an action that the AWS Step Function will carry out. There are several sorts of states that give flexibility to your operation.
2. Transitions
You will continue to the next state after performing an action indicated by the state. Some states permit the creation of loops, allowing the following state to be the same in a subsequent iteration.
3. Task
Carry out an action that can be carried out by integrating with a variety of AWS services. Invoking a Lambda function (which can then perform pretty much anything), sending a message through SQS, or accessing an API supported by the API Gateway service, are all common instances. Also, AWS is constantly expanding the range of services that may be accessed directly.
4. Choice
The state of “Task” as “Create Order in Pending” launches a Lambda function when one is specified in the “Resource” field.
Permit you to branch your workflow depending on a condition, often the outcome of a previous stage. If no direct condition matches, you might have a wide range of options, including a default decision.
It depicts a state that will assess the contents of a carrier variable and determine the next state to transition to depending on the values. The default option specifies that we should switch to the “Canada Post” state if no specific options meet the requirements.
5. Map
Permit executing a sequence of operations on each item in a list iteratively. When you need to incorporate a scatter-gather workflow, it is quite helpful.
Consider the scenario where your process must determine the delivery fee and it is based on the weight of each box.
You could get the list of packages and figure out how much each one would cost. You ultimately compile all the data given.
Because another workflow
Which may be as sophisticated as necessary
actually gets implemented in actuality, this condition is very potent. You can see that the Iterator object’s structure, which includes a StartAt element, a Next element, and so on, is the same as the workflow’s.
Controlling the iteration’s concurrency is crucial if one or more states are accessing external resources. If you leave Denial of Service (DoS) unchecked it attacks your own services or reaches a throttling cap, both possible.
Wrapping Up
So far, we have been able to see how to Implement Sagas Pattern Using AWS Step Functions. The AWS Step Function attempts to run as many iterations in parallel as feasible because the concurrency level by default is 0, the lowest allowable value. You may set the concurrency to 1 if you prefer a sequential method. You have control over the input it takes and the output it produces, and AWS will carry out each state. In its most basic form, the output from a prior state will serve as, or at the very least be accessible to, the input for the subsequent state.
