Saga Pattern for Distributed Transactions

The Saga pattern is a design pattern for managing distributed transactions across multiple services in a microservices architecture. Unlike traditional ACID transactions that use two-phase commit (2PC) to ensure atomicity across databases, Sagas break a distributed transaction into a sequence of local transactions, each with a compensating action that can undo its effects. This avoids holding locks on resources for long periods, improving system availability and scalability.

In a monolithic application, a single database can enforce ACID properties using transactions. However, in a microservices architecture, each service typically owns its own database, and distributed transactions across databases are difficult and costly. Two-phase commit (2PC) requires a coordinator and locks resources, which can lead to blocking and reduced availability. Sagas provide a way to maintain data consistency without distributed locking, using eventual consistency and compensating actions.

A Saga is a sequence of steps, each step being a local transaction that updates data within a single service and publishes a message or event. If a step fails, the Saga executes compensating transactions in reverse order to undo the effects of previous steps. There are two primary coordination approaches:

To implement a Saga on Azure:

Example orchestrator function (C#):

[FunctionName("OrderSaga")]
public async Task Run(
    [OrchestrationTrigger] IDurableOrchestrationContext context)
{
    var input = context.GetInput<OrderSagaInput>();
    var compensationActions = new List<Func<Task>>();

    try
    {
        // Step 1: Reserve Inventory
        await context.CallActivityAsync("ReserveInventory", input.OrderId);
        compensationActions.Add(() => context.CallActivityAsync("ReleaseInventory", input.OrderId));

        // Step 2: Process Payment
        await context.CallActivityAsync("ProcessPayment", input.PaymentInfo);
        compensationActions.Add(() => context.CallActivityAsync("RefundPayment", input.PaymentInfo));

        // Step 3: Ship Order
        await context.CallActivityAsync("ShipOrder", input.OrderId);
        compensationActions.Add(() => context.CallActivityAsync("CancelShipment", input.OrderId));

        // All steps succeeded
        await context.CallActivityAsync("UpdateOrderStatus", new { OrderId = input.OrderId, Status = "Completed" });
    }
    catch (Exception ex)
    {
        // Execute compensations in reverse order
        for (int i = compensationActions.Count - 1; i >= 0; i--)
        {
            await compensationActions[i]();
        }
        await context.CallActivityAsync("UpdateOrderStatus", new { OrderId = input.OrderId, Status = "Failed" });
    }
}

- Monitor Durable Functions status:

az durabletask orchestrator list --task-hub-name MyTaskHub

- Check Saga log in Cosmos DB:

SELECT * FROM c WHERE c.sagaId = 'order-123' ORDER BY c._ts DESC

For AZ-305, understand when to choose Sagas over 2PC or eventual consistency. The exam tests scenarios where Sagas are appropriate (e.g., long-running business processes, multiple services with independent databases) and where they are not (e.g., single database, low latency requirements).

A large online retailer uses microservices for inventory, payment, shipping, and notification. When a customer places an order, the system must reserve inventory, charge the credit card, ship the item, and send a confirmation. If the credit card is declined after inventory is reserved, the inventory must be released. The Saga pattern is implemented using Azure Durable Functions as the orchestrator. Each step calls a separate Azure Function that updates its own Azure SQL Database or Cosmos DB collection. The saga log is stored in Cosmos DB with a TTL of 30 days. Performance considerations: the entire saga must complete within 2 minutes to avoid customer timeout. The orchestrator uses retry policies with exponential backoff (initial delay 1 second, max 30 seconds, 3 retries). Common issues: if the inventory reservation times out but the database actually committed, the compensation may not run, leaving inventory locked. To mitigate, the compensation action queries the database to verify the state before releasing.

A travel agency books flights, hotels, and car rentals across multiple providers. Each booking is a separate service with its own database. The Saga pattern coordinates the booking: first book flight, then hotel, then car. If the car rental fails, the hotel and flight bookings must be cancelled. The system uses choreography with Azure Service Bus topics. Each service publishes an event (e.g., FlightBooked). The next service listens and proceeds. If a service fails, it publishes a CompensationRequired event, and all previous services listen and execute their compensating actions. Challenge: handling concurrent bookings for the same hotel room. The hotel service uses optimistic concurrency with version numbers; if a conflict occurs, it fails the step and triggers compensation. Scale: the system handles 10,000 bookings per hour. Saga logs are stored in Azure Table Storage for cost efficiency.

A bank transfers money between accounts in different regions. Each account is in a separate database (Azure SQL Database in different regions). The Saga pattern ensures that debit and credit are atomic. Step 1: Debit from source account. Step 2: Credit to destination account. If credit fails, debit is reversed. The orchestrator runs in Azure Functions with geo-redundant storage for saga logs. Compensation must be exact: if the debit was $100, the credit compensation must credit $100 back. Idempotency keys are used to prevent duplicate reversals. Performance: the saga must complete within 5 seconds to meet SLA. The system uses Azure Redis Cache for temporary state to reduce latency. Misconfiguration: if the compensation is not idempotent and the orchestrator retries, the customer may be refunded twice. The bank implements a check: before compensating, it verifies that the original debit was not already reversed.