Demystifying Saga Design Pattern in C#: A Cure for Distributed Transactional Woes

In the world of distributed systems, managing transactions across different services can often pose a significant challenge. Traditional approaches like the 2-Phase commit and 3-Phase commit patterns have been reliable companions in monolithic applications, yet they fall short when it comes to modern, distributed environments. This article explores the Saga Design Pattern, a powerful approach that addresses these issues in a distributed setting. We will delve into its definition, types, and the concept of compensation, illustrated with a real-world e-commerce platform example.

The Problem at Hand

When it comes to transactions in a monolithic architecture, the typical approach is the ACID (Atomicity, Consistency, Isolation, Durability) model, with distributed transactions implemented via the 2-Phase or 3-Phase commit patterns. However, these models run into scalability and performance issues in distributed systems.

In the world of microservices, transactions might span across multiple services, each having its own database. Enforcing ACID principles in such a context introduces tight coupling between services and leads to an overall system fragility. More so, it is a Herculean task to maintain a global transaction lock in distributed systems, resulting in significant latency.

Enter the Saga Pattern

The Saga Design Pattern emerged as a solution to these issues. A Saga is a sequence of local transactions where each transaction updates data within a single service. The failure of a local transaction triggers the saga’s compensation mechanism, which executes compensating transactions to undo the impact of the preceding local transactions.

The key advantage of the Saga pattern is that it ensures data consistency across multiple services and databases without locking resources, thus eliminating the latency issues inherent in traditional distributed transactions.

Saga Types: Choreography and Orchestration

Sagas mainly come in two types: Choreography and Orchestration.

1. Choreography: In choreography, each local transaction publishes an event upon success. Other local transactions subscribe to these events and execute when their conditions are met. While this approach reduces the need for centralized coordination, it can be complex to understand and monitor due to its distributed nature.

2. Orchestration: In orchestration, there's a central coordinator (often called an orchestrator) that tells other services to execute local transactions. This approach is easier to understand and manage because the saga execution logic is in one place. However, it can also become a bottleneck and a single point of failure if not designed properly.

Compensation and the E-Commerce Example

A unique aspect of the Saga pattern is its compensation mechanism, which undoes a transaction when a subsequent transaction in the saga fails. Let's illustrate this with an e-commerce platform example.

Consider a typical purchase saga:

1. User places an order.
2. Payment is processed.
3. Order is confirmed and shipped.

In C#, each of these steps could be handled by different services:

In this model, each step of the saga is a command handled by a specific Handler, which provides Execute and Compensate methods.

Below is an example of such a saga pattern in a .NET e-commerce application:

public interface ICommandHandler
{
    Task<bool> Execute();
    Task Compensate();
}

// Command and Handler for PlaceOrder
public class PlaceOrderCommand
{
    public Order Order { get; set; }
}

public class PlaceOrderCommandHandler :ICommandHandler
{
    public async Task<bool> Execute(PlaceOrderCommand command) 
    {
        // Logic to place the order
        // If successful, return true
        // If not, return false
    }

    public async Task<bool> Compensate(PlaceOrderCommand command) 
    {
        // Logic to cancel the order
        // If successful, return true
        // If not, return false
    }
}

// Command and Handler for ProcessPayment
public class ProcessPaymentCommand
{
    public Payment Payment { get; set; }
}

public class ProcessPaymentCommandHandler :ICommandHandler
{
    public async Task<bool> Execute(ProcessPaymentCommand command) 
    {
        // Logic to process the payment
        // If successful, return true
        // If not, return false
    }

    public async Task<bool> Compensate(ProcessPaymentCommand command) 
    {
        // Logic to refund the payment
        // If successful, return true
        // If not, return false
    }
}

// Command and Handler for ConfirmAndShipOrder
public class ConfirmAndShipOrderCommand
{
    public Order Order { get; set; }
}

public class ConfirmAndShipOrderCommandHandler :ICommandHandler
{
    public async Task<bool> Execute(ConfirmAndShipOrderCommand command) 
    {
        // Logic to confirm and ship the order
        // If successful, return true
        // If not, return false
    }

    public async Task<bool> Compensate(ConfirmAndShipOrderCommand command) 
    {
        // Logic to cancel the shipment and revert the order to its initial state
        // If successful, return true
        // If not, return false
    }
}

And the Orchestratave saga class 

public class PurchaseSaga 
{
    private Queue<ICommandHandler> _handlerQueue;
    private Stack<ICommandHandler> _completedHandlers;

    public PurchaseSaga(
        PlaceOrderCommandHandler placeOrderHandler, 
        ProcessPaymentCommandHandler paymentHandler, 
        ConfirmAndShipOrderCommandHandler shippingHandler)
    {
        _handlerQueue = new Queue<ICommandHandler>();
        _completedHandlers = new Stack<ICommandHandler>();

        _handlerQueue.Enqueue(placeOrderHandler);
        _handlerQueue.Enqueue(paymentHandler);
        _handlerQueue.Enqueue(shippingHandler);
    }

    public async Task Execute() 
    {
        while (_handlerQueue.Count > 0) 
        {
            var handler = _handlerQueue.Dequeue();

            if (await handler.Execute()) 
            {
                _completedHandlers.Push(handler);
            } 
            else 
            {
                await Compensate();
                return;
            }
        }
    }

    private async Task Compensate() 
    {
        while (_completedHandlers.Count > 0) 
        {
            var handler = _completedHandlers.Pop();
            await handler.Compensate();
        }
    }
}

In this version, PurchaseSaga maintains a queue of ICommandHandler instances to execute, and a stack of ICommandHandler instances that have been completed. Each ICommandHandler interface has two methods: Execute and Compensate.

The Execute method de-queues handlers from the queue and executes them, pushing successful handlers onto the stack. If a handler fails to execute, the Compensate method is called, which pops handlers from the stack and calls their Compensate method.

This approach keeps track of exactly what has been done and needs to be undone if the saga cannot be completed, improving clarity and maintainability of the code.

Wrapping Up

The Saga Design Pattern presents a powerful alternative to traditional transaction models in the realm of distributed systems. By embracing local transactions and a robust compensation mechanism, sagas enable the building of scalable, consistent, and resilient systems in the face of failure. While understanding and implementing sagas require a fair degree of care, their benefits for complex, distributed applications are indisputable.