Saga Pattern for Distributed Transactions: Architecture Guide

Distributed transactions in microservices break the ACID guarantees you took for granted in monoliths. A business operation spanning three services—order creation, payment processing, and inventory reservation—can partially succeed, leaving the system in an inconsistent state. The saga pattern is the production-proven answer: orchestrate a sequence of local transactions, each with a compensating action to undo it if a later step fails.

Architecture at a glance

Saga Pattern for Distributed Transactions: Architecture Guide — diagram — Saga Pattern for Distributed Transactions: Architecture Guide

But sagas are deceptively hard. They require idempotency keys, saga log durability, compensation design, and careful timeout handling. And the choice between choreography (event-driven) and orchestration (central coordinator) is architectural—it shapes your observability, failure modes, and operational complexity. Modern workflow engines—Temporal, AWS Step Functions, Camunda Zeebe, Azure Durable Functions—have matured to the point where orchestrated sagas are now the default choice, not the exception.

This deep dive walks through the anatomy of a saga, compares choreography and orchestration with a worked order-processing example, covers the hard production requirements, and explains when and how to use modern workflow engines.

What a Saga Pattern Is (and Isn’t)

A saga is a sequence of local transactions—each on a single service or database—that together model a distributed business operation. When a saga step fails, the saga coordinator (or event listeners, in choreography) trigger compensating transactions to undo prior steps in reverse order. This guarantees eventual consistency: either the saga completes end-to-end, or it rolls back entirely.

The key insight is that you cannot use two-phase commit (2PC) across services. 2PC requires a distributed lock manager that blocks resources until all participants vote commit. In a microservices system, this locks inventory while payments are processing, which is unacceptable at scale. Sagas trade immediacy for resilience: they accept intermediate inconsistency, but guarantee that the system converges to a valid state—all-or-nothing semantics, eventually.

Sagas are not:
– Transactions in the ACID sense. A saga’s isolation level is weaker than ACID (you may see partial writes mid-saga). However, if you design compensations correctly, the outcome is still atomic—either the saga succeeds or reverts fully.
– A substitute for event sourcing. Sagas orchestrate state changes; event sourcing records them. You can use both together, but they solve different problems. Sagas handle long-lived workflows; event sourcing handles immutable history and audit trails.
– A replacement for saga databases (some vendors market saga-specific transactional engines). A saga pattern works with any database—PostgreSQL, MongoDB, DynamoDB—as long as you can write compensating logic.

The saga pattern emerged from research on long-running business transactions in the 1980s but has seen explosive adoption in microservices since 2014, as teams discovered 2PC wasn’t viable at their scale.

Choreography vs Orchestration: Architectures Compared

The fundamental choice in saga design is who drives the workflow: services react to events (choreography) or a central coordinator commands each step (orchestration). Both work; they have radically different properties.

Choreography: Event-Driven Sagas

In choreography, there is no central coordinator. Services emit events when they complete a local transaction. Other services listen to those events and trigger their own transactions—forming a chain of causality.

Example: order processing via choreography
1. Order Service receives a POST /orders request and creates an Order (status=pending).
2. Order Service emits an OrderCreated event.
3. Payment Service consumes the event, processes the payment, and emits PaymentCompleted.
4. Inventory Service consumes PaymentCompleted, reserves stock, and emits InventoryReserved.
5. Order Service consumes InventoryReserved, marks the order as confirmed (status=confirmed).

If payment fails:
1. Payment Service emits PaymentFailed.
2. Order Service consumes it, marks the order as failed (status=failed).
3. No compensation is needed yet—nothing past payment has been committed.

But if payment succeeds and inventory reservation fails:
1. Inventory Service emits InventoryReservationFailed.
2. Payment Service consumes it, refunds the customer (compensating transaction).
3. Order Service marks the order as failed.

Advantages:
– Loose coupling. Services don’t know about each other directly; they only emit and consume events. Swap out a payment provider without touching the order service.
– Scalable event routing. Use a message broker (RabbitMQ, Kafka) to fan-out events; the broker handles delivery, not your application.
– Natural for event sourcing. If you’re already capturing events for audit or analytics, choreography feels native.

Disadvantages:
– Distributed control flow is opaque. The saga flow is scattered across multiple services and event handlers. Understanding “what happens when this order is placed” requires reading code in three services.
– Error handling is ad-hoc. Each service implements compensation logic independently. There’s no central place to see what will happen if the saga fails. Testing compensation paths is laborious.
– Cyclic dependencies and infinite loops. If Service A emits an event that triggers Service B, which emits an event that triggers Service A, you can accidentally create a loop. Defensive programming (checking idempotency keys, saga state) becomes mandatory.
– No global saga state. There’s no single source of truth for whether the saga is in progress, succeeded, or is being compensated. Observability requires correlating events across multiple logs.
– Compensation is not ordered. If a saga with five steps fails at step 4, choreography doesn’t guarantee compensations run in reverse order. You must design each compensation to be idempotent and to work regardless of the order other compensations run.

Orchestration: Central Coordinator

In orchestration, a dedicated service (the saga orchestrator) owns the workflow. It calls each service in sequence, receives responses, and decides the next step. If any step fails, the orchestrator explicitly calls compensation steps in reverse order.

Example: order processing via orchestration
1. Order Service posts to Orchestrator: StartOrderSaga(order_id=123, amount=$50, items=[...]).
2. Orchestrator calls Payment Service: ChargeCard(amount=$50). Payment Service returns success.
3. Orchestrator calls Inventory Service: ReserveStock(items=[...]). Inventory returns success.
4. Orchestrator calls Order Service: ConfirmOrder(order_id=123). Order confirmed.
5. Orchestrator responds to caller: saga succeeded.

If inventory reservation fails at step 3:
1. Orchestrator receives the failure response.
2. Orchestrator calls Payment Service: RefundCard(charge_id=X). Payment Service refunds.
3. Orchestrator calls Inventory Service: CancelReservation(reservation_id=Y) (if needed).
4. Orchestrator calls Order Service: FailOrder(order_id=123).
5. Orchestrator responds to caller: saga failed.

Advantages:
– Centralized control flow. The saga workflow is defined in one place, often in a DSL or a state machine. Understanding “what happens in an order saga” requires reading one file.
– Explicit error handling. The orchestrator defines compensations for each step upfront. Testing is straightforward: mock the services, trigger a failure at each step, and verify compensation logic.
– No cyclic dependencies. The orchestrator is the only component that has causal knowledge of the entire flow. Services are stateless from the orchestrator’s perspective.
– Global saga state. The orchestrator maintains the saga status (running, succeeded, failed, being_compensated). You can query it to understand what’s happening.
– Ordered compensation. If the saga fails, the orchestrator walks backward through the completed steps in reverse order, calling compensation logic deterministically.

Disadvantages:
– Tight coupling. The orchestrator knows about and calls every service. Adding a new step requires changing the orchestrator. Substituting a payment provider means updating the orchestrator’s code.
– Orchestrator as a bottleneck. The orchestrator is a single point of failure and a throughput limiter. If it crashes mid-saga, in-flight sagas hang. You must make the orchestrator itself highly available and persistent.
– Complex state machine. As sagas grow (6+ steps), the orchestrator becomes a complex state machine with branching logic. Testing all paths is exponential in complexity.
– Retry and idempotency are your responsibility. The orchestrator must handle timeouts, retries, and ensure services are idempotent. If you call a service twice, it must accept the second call as a no-op.

Decision Rubric

Property	Choreography	Orchestration
Saga complexity	Simple (2–3 steps)	Any complexity
Observability	Hard; events scattered across services	Easy; centralized state machine
Error handling	Ad-hoc, distributed logic	Explicit, centralized
Service coupling	Loose	Tight
Testability	Low; many integration paths	High; mock services easily
Orchestrator overhead	None	High (availability, state durability)

Recommendation: Start with orchestration unless you have a strong reason to go choreography (e.g., you’re already event-sourcing and want to minimize components). Orchestration trades operational simplicity for a new dependency; choreography trades operational simplicity for distributed complexity.

Production Sagas: The Hard Parts

Choreography and orchestration are the architectural styles. Now the hard parts: making sagas reliable at scale requires idempotency, saga log durability, compensation design, and timeout handling.

Idempotency Keys

A network may timeout partway through a saga step. The caller retries. But the service may have already committed the transaction. A second charge, a second inventory reservation—now the saga is broken.

The solution is idempotency keys: a unique identifier for each logical operation, provided by the client. The service stores this key alongside every state mutation. When a retry arrives with the same key, the service returns the cached result without re-executing.

Example:

POST /charge
{
  "idempotency_key": "saga_123_step_2_charge",
  "amount": 50,
  "currency": "USD"
}

The payment service stores (idempotency_key, transaction_id, result) in a side table. If the same key arrives again, return the cached result. Idempotency keys must be universally unique and deterministic per saga step—usually, saga_id + step_number or a UUID computed from the saga ID.

Idempotency keys must be persisted (not in-memory). If your payment service crashes, the next request with the same key must still find the cached result.

Saga Log Durability

The orchestrator (or saga coordinator) must persist the saga state to durable storage before orchestrating each step. Why? If the orchestrator crashes after calling Payment Service but before updating its local state, a restart doesn’t know a payment was issued. A retry might charge the customer twice.

The pattern is:
1. Orchestrator durably stores: (saga_id, step_number, status, result).
2. Orchestrator calls Payment Service.
3. Payment Service returns success.
4. Orchestrator durably updates: (saga_id, step_number+1, in_progress, null).
5. Orchestrator calls Inventory Service.
6. … and so on.

If the orchestrator crashes between steps 4 and 5, recovery simply resumes at step 4, knowing the payment succeeded (it’s in the log).

Saga log entries don’t need to be in the same database as the orchestrator. They can live in a dedicated saga state store (DynamoDB, PostgreSQL, etcd) or even in an append-only event log if you’re using event sourcing.

Compensation Design

Writing compensations is domain-specific and error-prone. A refund is not the inverse of a charge (refunds cost fees, may fail, may take days to settle). Reservation cancellation is not the inverse of reservation—if the customer picked up the order before cancellation, it’s moot.

Guidelines:
– Compensations are best-effort, not atomic. If a compensation fails, it should be retryable and idempotent, not cause cascading failures.
– Compensations are not “undo.” A refund is a new transaction, not a rollback. It has different business semantics (it may be partial, taxed differently, logged separately).
– Some operations don’t need compensation. If a saga fails before step 3 (notification to the customer), there’s nothing to undo; the notification was never sent. Distinguish between steps that change state (need compensation) and steps that don’t.
– Semantic rollback is not always possible. Once a notification is sent to a user (“Your order shipped”), you can’t unsend it. Compensations for such steps are often just logging or marking the saga as failed, not reversing the user-visible action.

Timeouts and Retries

A saga step may hang indefinitely if the service is slow or down. The orchestrator must define a timeout per step—often 10 seconds to 5 minutes, depending on the operation. If a step times out, the orchestrator can:
– Retry the step (if idempotent).
– Fail the saga and trigger compensations.
– Escalate to a human (if the operation is critical and compensation is dangerous).

Retries should be exponential backoff, not immediate. And retries must have a cap—after N attempts, fail the saga. A service that’s down for 30 minutes should not cause sagas to retry for hours.

Modern Workflow Engines

Building sagas from scratch—managing orchestrator state, idempotency, saga logs, retries, compensation DAGs—is error-prone. Modern workflow engines encapsulate all of this. They’ve matured enough that using an engine is now the default, not an optimization.

Temporal (Temporal.io)

Temporal is a workflow orchestration engine, purpose-built for complex distributed workflows. It’s open-source and runs as a managed service (Temporal Cloud) or self-hosted.

Key concepts:
– Workflows are defined in code (TypeScript, Go, Python, Java). They’re deterministic functions that call activities (long-running operations on external services).
– Activities are the saga steps—they call your Payment Service, Inventory Service, etc.
– Automatic durability. Temporal persists workflow execution state in its event store. If a workflow crashes mid-execution, it resumes from the last checkpoint.
– Compensations as logic. In Temporal, a compensation is just cleanup code in a finally block or a defer statement. Temporal ensures it runs if the workflow fails.

Example (pseudocode):

func OrderWorkflow(ctx context.Context, order Order) (OrderResult, error) {
    opts := workflow.ActivityOptions{
        ScheduleToStartTimeout: 10 * time.Second,
        StartToCloseTimeout:    5 * time.Minute,
    }
    ctx = workflow.WithActivityOptions(ctx, opts)

    var paymentID string
    err := workflow.ExecuteActivity(ctx, ChargeCard, order.Amount).Get(ctx, &paymentID)
    if err != nil {
        // Compensation: refund
        workflow.ExecuteActivity(ctx, RefundCard, paymentID)
        return OrderResult{}, err
    }

    var reservationID string
    err = workflow.ExecuteActivity(ctx, ReserveInventory, order.Items).Get(ctx, &reservationID)
    if err != nil {
        // Compensation: refund charge
        workflow.ExecuteActivity(ctx, RefundCard, paymentID)
        return OrderResult{}, err
    }

    // Success
    workflow.ExecuteActivity(ctx, ConfirmOrder, order.ID)
    return OrderResult{Status: "confirmed"}, nil
}

Advantages:
– Deterministic replay: Temporal replays a workflow’s execution history to recover from crashes. If a decision is made at step 5, replaying resumes from step 6.
– Language-neutral: Workflows are code, not a DSL. Use familiar programming constructs (loops, conditionals, error handling).
– Built-in observability: Temporal UI shows the entire execution history, including activities, retries, and timings.

Disadvantages:
– Operational complexity: Running Temporal requires a Cassandra or PostgreSQL backend, coordination service, and history server. Self-hosted Temporal is non-trivial.
– Determinism constraint: Workflow code must be deterministic (no random numbers, no external calls). This takes discipline.

AWS Step Functions

Step Functions is AWS’s orchestration service. It’s serverless, managed by AWS, and deeply integrated with other AWS services.

Key concepts:
– Workflows are defined in AWS States Language (ASL), a JSON-based DSL.
– States include Task (call Lambda, service API), Choice (branching), Parallel, Wait, etc.
– Error handling and retries are declarative (Retry, Catch clauses per state).
– Compensations are explicit states (Compensate) or cleanup lambdas.

Example (pseudocode):

{
  "StartAt": "ChargeCard",
  "States": {
    "ChargeCard": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:function:chargeCard",
      "Catch": [
        {
          "ErrorEquals": ["States.TaskFailed"],
          "Next": "FailOrder"
        }
      ],
      "Next": "ReserveInventory"
    },
    "ReserveInventory": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:function:reserveInventory",
      "Catch": [
        {
          "ErrorEquals": ["States.TaskFailed"],
          "Next": "RefundCharge"
        }
      ],
      "Next": "ConfirmOrder"
    },
    "RefundCharge": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:function:refundCard",
      "Next": "FailOrder"
    },
    "ConfirmOrder": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:...:function:confirmOrder",
      "Next": "SuccessOrder"
    },
    "SuccessOrder": { "Type": "Succeed" },
    "FailOrder": { "Type": "Fail" }
  }
}

Advantages:
– No operational overhead: AWS manages the service. Scale is automatic.
– Native integration with Lambda, DynamoDB, SNS, SQS, etc.
– Lightweight for simple to moderate workflows.

Disadvantages:
– DSL learning curve: ASL is JSON-based and verbose.
– Limited expressiveness: complex conditional logic or loops require nested states.
– Vendor lock-in: Step Functions is AWS-only.

Camunda Zeebe

Zeebe is an open-source workflow engine emphasizing horizontal scalability and cloud-native deployment.

Key concepts:
– Workflows are modeled in BPMN 2.0 (Business Process Model and Notation), a standardized diagramming language.
– Workers subscribe to job queues and pull tasks from Zeebe.
– Scaling is horizontal: add more workers or brokers to handle more workflows.
– Event-driven: Zeebe can emit events that other systems consume.

Advantages:
– BPMN is visual and standardized: non-engineers can read workflow diagrams.
– Horizontal scalability by design: Zeebe partitions workflows and load-balances across brokers.
– Open-source and self-hosted.

Disadvantages:
– BPMN adds abstraction: it’s powerful but has a steeper learning curve than code.
– Worker management overhead: you own the workers and their availability.

Azure Durable Functions

Microsoft’s equivalent of Temporal and Step Functions. Durable Functions extend Azure Functions (serverless compute) with state management for long-running workflows.

Key concepts:
– Orchestrator functions define the workflow (C#, Python, TypeScript).
– Activity functions are the long-running operations.
– The Durable Functions runtime persists checkpoints and replays history.
– Sub-orchestrators allow workflow composition.

Advantages:
– Integrated with Azure ecosystem (Azure Service Bus, Cosmos DB, etc.).
– Code-first (like Temporal): workflows are C# or TypeScript functions.
– Managed service: no infrastructure to run.

Disadvantages:
– Azure-only; not portable.
– History-based replay (like Temporal): determinism constraints apply.

Decision Rubric for Engines

Criterion	Temporal	Step Functions	Zeebe	Durable Functions
Operational complexity	High (self-hosted)	Low (serverless)	Medium (Kubernetes)	Low (serverless)
Vendor lock-in	None (OSS)	AWS-only	None (OSS)	Azure-only
Language support	Go, TypeScript, Java, Python	Lambda only	Any (via workers)	C#, Python, TS
Expressiveness	Code + DSL	DSL (ASL)	BPMN visual	Code
Observability	Excellent (Temporal UI)	Good (CloudWatch)	Good (Zeebe UI)	Good (Azure Portal)
Pricing model	Per-host or managed tier	Per-execution + duration	Self-hosted (free)	Per-execution

Recommendation: For a new microservices system, start with a managed engine (Step Functions if AWS, Durable Functions if Azure, Temporal Cloud if multi-cloud). If you need maximum control and horizontal scale, Zeebe or self-hosted Temporal. Don’t build a custom orchestrator unless you have extraordinary requirements.

Trade-offs and Gotchas

Semantic Rollback

Not all operations can be undone. If a saga successfully ships a package and then payment fails, canceling the shipment is a new decision, not a rollback. This is called semantic rollback: the compensation is a business decision, not a technical undo.

Example: an e-commerce order saga ships the order, then the payment fails. Compensation isn’t “unsend the package”; it’s “flag the order for return and notify the customer.” You can’t undo the shipment, but you can handle the failure gracefully.

Sagas are excellent for semantic rollback because they allow you to define domain-specific compensations. Treat compensations as first-class business logic, not an afterthought.

Double-Compensation and Idempotency

If a saga fails, compensations run. But what if a compensation times out? The orchestrator retries it. What if the compensation actually succeeded but the acknowledgment was lost? Now compensation runs twice.

This is why all compensations must be idempotent. Running a refund twice with the same idempotency key must produce the same result (a single refund). Calling an inventory cancellation twice must be a no-op the second time.

Idempotency is the foundation of saga reliability. It’s not optional.

Distributed Saga Debugging

A saga failure often involves multiple services, each with its own logs. Debugging why a saga failed requires correlating logs across services. This is slow and error-prone without structured correlation IDs.

Best practice: Every saga instance has a unique saga_id. Pass it to every service in every request. Log the saga_id in every service’s logs. Use centralized logging (ELK, DataDog, Honeycomb) to correlate logs by saga_id.

Modern engines (Temporal, Step Functions, Zeebe) handle this internally and expose the execution history in their UI. This is a significant operational advantage over choreography.

Event Sourcing and Sagas

Event sourcing and sagas are orthogonal but complementary. Event sourcing records every state change as an immutable event. Sagas orchestrate sequences of changes.

You can use both: a saga orchestrates changes to an aggregate, and each change is published as an event. The event log becomes your audit trail and source of truth. However, don’t conflate them: a saga is not an event; it’s a workflow. An event is immutable history; a saga is in-flight action.

Compensation Ordering and Nested Sagas

If a saga has 10 steps and fails at step 7, compensations for steps 1–6 must run. But do they run in reverse order? Must they run serially or can they run in parallel?

Orchestration provides strong guarantees: compensations run in reverse order, serially (unless you explicitly parallelize). Choreography doesn’t: compensations are independent events, and ordering is not guaranteed. You must design each compensation to be idempotent and order-independent.

For nested sagas (a saga calls another saga as a step), the outer saga’s compensation must be aware that the inner saga may have already compensated itself. Otherwise, you end up double-compensating.

Best practice: Keep sagas shallow (5–8 steps max). If you need nesting, use sub-orchestrators (if your engine supports them) and define compensation rules explicitly.

Practical Recommendations

Choose orchestration for most sagas. Choreography is tempting because it feels decoupled, but the operational burden (observability, error handling, testing) usually outweighs the benefit. Orchestration gives you a clear point of control.
Use a workflow engine, don’t build one. Temporal, Step Functions, Zeebe, or Durable Functions are mature enough to handle your requirements. The cost of a custom orchestrator (in bugs, operations, and maintenance) is not worth it.
Design compensations as first-class business logic. A compensation is not “undo the payment”; it’s “refund the customer.” Define compensations upfront, test them independently, and document why each one exists.
Make every service idempotent. Every method that mutates state should accept and respect an idempotency key. This is the foundation of saga reliability, retry safety, and graceful degradation.
Persist saga state durably. Before orchestrating any step, persist the saga state. If your orchestrator crashes, recovery must know exactly where to resume.
Implement correlation IDs. Every saga has a unique ID. Pass it to every service in every request. Use centralized logging to correlate logs by saga_id. This reduces debugging time from hours to minutes.
Set realistic timeouts. Timeouts should be specific to the operation. Charging a card is fast (5 seconds); shipping an order takes hours. Use the right timeout for each step.
Test compensations, not just happy paths. Every saga needs integration tests that trigger failures at each step and verify compensations run correctly. Choreography makes this hard; orchestration makes it tractable.

FAQ

What is the saga pattern?

The saga pattern is a way to manage distributed transactions across microservices. A saga is a sequence of local transactions (each on a single service) with compensating transactions that undo prior steps if a later step fails. Sagas guarantee eventual consistency: either the entire saga succeeds or it fails and rolls back entirely.

Should I use choreography or orchestration sagas?

Orchestration is the better default. It’s easier to test, understand, and debug. Choreography is loose coupling, but the operational complexity often outweighs the benefit. Use choreography only if you’re already event-sourcing and the flow is simple (2–3 steps).

Is Temporal a saga framework?

Temporal is a workflow orchestration engine that can implement sagas, but it’s broader. Temporal is for any long-running, fault-tolerant workflow—sagas, batch processes, temporal business logic, etc. Temporal provides the persistence, retry, timeout, and compensation infrastructure that sagas need, but you still design and code the workflow.

What’s the difference between saga and two-phase commit (2PC)?

2PC is atomic across all participants: all-or-nothing, immediately. But 2PC locks resources (blocking others from accessing them) and fails if any participant is unavailable. Sagas are eventually consistent: they accept intermediate inconsistency, but avoid locking and work even if services are temporarily down. Sagas are the right choice for microservices at scale.

How do you test distributed sagas?

Mock each service and simulate failures at each step. Verify that compensations run in the right order and idempotently. Use a workflow engine’s test harness (Temporal has good testing support) to avoid integration test overhead. For choreography, test in a messaging sandbox; for orchestration, test by mocking service calls and verifying the orchestrator’s state transitions.

Schema Markup

{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "Saga Pattern for Distributed Transactions: Architecture Guide",
  "description": "Saga pattern in production — choreography vs orchestration, compensating actions, idempotency, saga log durability, and how Temporal and Camunda reshape sagas in 2026.",
  "image": "/wp-content/uploads/2026/04/saga-pattern-distributed-transactions-architecture-guide-hero.jpg",
  "author": {
    "@type": "Person",
    "name": "Riju"
  },
  "publisher": {
    "@type": "Organization",
    "name": "iotdigitaltwinplm.com"
  },
  "datePublished": "2026-04-23T18:30:00+05:30",
  "dateModified": "2026-04-23T18:30:00+05:30",
  "mainEntityOfPage": "https://iotdigitaltwinplm.com/cloud-devops/saga-pattern-distributed-transactions-architecture-guide/",
  "proficiencyLevel": "Expert"
}

Saga Pattern for Distributed Transactions: Architecture Guide

Saga Pattern for Distributed Transactions: Architecture Guide

Architecture at a glance

What a Saga Pattern Is (and Isn’t)

Choreography vs Orchestration: Architectures Compared

Choreography: Event-Driven Sagas

Orchestration: Central Coordinator

Decision Rubric

Production Sagas: The Hard Parts

Idempotency Keys

Saga Log Durability

Compensation Design

Timeouts and Retries

Modern Workflow Engines

Temporal (Temporal.io)

AWS Step Functions

Camunda Zeebe

Azure Durable Functions

Decision Rubric for Engines

Trade-offs and Gotchas

Semantic Rollback

Double-Compensation and Idempotency

Distributed Saga Debugging

Event Sourcing and Sagas

Compensation Ordering and Nested Sagas

Practical Recommendations

FAQ

Further Reading

Schema Markup

Related

Comments

Leave a Reply Cancel reply

Tag Cloud

Categories