Software Engineering Implant: SAGA Pattern

It is a way to manage data consistency across micro services in a distributed transaction scenario.
If any task fails, either the or Twitter service or all the services individually based on event, perform a roll back transaction.
Micro services is a way to design software as a Suit of independently, deployable services, usually around a business capability.
The Saga decomposes a long lived transaction into a series of smaller transaction distributed across multiple processes.
It guarantee that either all transactions in a saga pattern are executed successfully or compensating transaction are run To amend partial execution.
As the original paper on Saga’s Published by Hector Gracia-Malina In 1997, regarding the need for Saga. Long lived transactions(LLT’s) hold on to database resources for relatively longer periods of time, Significantly delaying the termination of shorter and more common transactions. To Eliminate these problems We propose the notion of a saga.

SAGA’s are also applicable to a monolith. They are applicable any time we cannot create a single database transaction.
In terms of domain driven design Saga is a perfect pattern whenever you have a business operation that spans multiple Bounded contexts.
Saga pattern helps to maintain acid transactions/communication between the micro services.

We can apply saga pattern with choreography approach or orchestration approach.
Each micro service executes a transaction, and if there is any error.In any of the micro service, we can provide an alternative action.
In orchestration, there is a single service that takes the responsibility of calling all the other services in the right order which Perform different transactions.

Orchestration Is centralised.
A Service Is responsible for the invocation of all continuation or compensation steps.
In this approach, the orchestrator Is unilaterally Dependent on the Saga participants. The participants are fully decoupled between themselves.
The workflow is more readable And predictable since it is defined entirely in the orchestrator codebase.
The caller service twice to make it look like one transaction And if there is any error It performs the necessary fallback mechanism that is take a compensating action.
In Orchestration We are expecting a response after each call to the service by mail service responsible for orchestration Hence, communication here is synchronous
The only drawback of this approach is that it introduces a new service, which needs to be designed and implemented while creating an additional point of failure.
There are already many solutions for this like AWS step functions, Azure logic apps, Apache airflow.
It Let’s developer to focus on defining the workflow code In its preferred language. While leaving the durability and resiliency consistent to the platform.

In choreography, we have a Central service or orchestrater that shows that all the services connect together. The communication between service happens via events.

Choreography is the decentralised.
In the choreography approach the execution flow approach is distributed among services. Each service is responsible to trigger a continuation, step or a compensation step.
It is usually done with events to maximise the decoupling between services.
Service react to events and know what to do or what to compensate in case something doesn’t work.
This communication can be optimised by choreography, which uses a synchronous communication where a broker like rabbit, MQ or Kafka Helps in retaining response until it is consumed by Consumer micro service.
In choreography, we do not have to wait for our response. More than once, service can consume a response and processes accordingly.
Saga’s With many participating services are difficult to manage with choreography.
The scope of entire saga is not immediately evident but requires opening from one micro service base to the next, thus making it difficult to understand and readable.
There may be cycling dependencies between services if we are using synchronous Invocation.
Finally, integration testing is difficult because we need all services in place to simulate a transaction.
In such Scenarios, we can implement orchestration where the execution flow control is centralised.

Events can be persisted for analysis later on this is called as event sourcing.
Alternatives to Saga can be two phase or three phase commits or some transactional engine like atomicos or bitronix. How these alternatives can increase complexity and reduce performance as they need to communicate synchronously during the transaction.

Event Driven Micro-services using Spring Boot and Apache Kafka

Event driven architecture(EDA) Is a software design pattern in which decoupled application Can asynchronously Publish and subscribe to events via an event Broker/Message broker.
In an event driven architecture Applications communicate with each other by sending and receiving events, or messages.
Event Driven Architecture is often referred to as “asynchronous” communication.
Event Driven apps can be created in any programming language because event driven is a programming approach and not a language.
An event driven architecture Is loosely coupled.

Software Engineering Implant