{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihu5pe5dk67v3rxlzbtx3wkursvj3aiulcrqq73cur5uslxtkbi2a",
    "uri": "at://did:plc:5sgu76a53rz3n6unbykmovqy/app.bsky.feed.post/3mlogas7ylj62"
  },
  "description": "A Saga is a pattern for executing a business transaction that spans multiple services or databases by chaining local transactions together, with compensating actions to roll back partial progress on failure. Sagas replace distributed transactions (two-phase commit) in microservice systems where global ACID across services is impractical.\n\n\nHow it works\n\nA saga breaks a business transaction into a sequence of steps. Each step is a local transaction in one service. If any step fails, the saga runs",
  "path": "/engineering-glossary/saga-distributed-transaction-pattern/",
  "publishedAt": "2026-05-12T18:29:50.000Z",
  "site": "https://sahilkapoor.com",
  "tags": [
    "Microservices",
    "Event-Driven Architecture",
    "Distributed Systems",
    "Idempotency",
    "Eventual Consistency"
  ],
  "textContent": "**A Saga** is a pattern for executing a business transaction that spans multiple services or databases by chaining local transactions together, with compensating actions to roll back partial progress on failure. Sagas replace distributed transactions (two-phase commit) in microservice systems where global ACID across services is impractical.\n\n## How it works\n\nA saga breaks a business transaction into a sequence of steps. Each step is a local transaction in one service. If any step fails, the saga runs compensating actions for all previously-completed steps to undo their effects. The saga ends when either all steps succeed or all compensations have run.\n\n## Two coordination styles\n\n  * **Choreography.** Services react to events from other services; no central coordinator. Easier to start, harder to reason about as the saga grows.\n  * **Orchestration.** A central saga orchestrator (a workflow engine or service) drives the sequence and decides what to do next. Easier to observe, debug, and modify; introduces one component that must be highly available.\n\n\n\n## Common workflow engines\n\n  * Temporal, Cadence, AWS Step Functions, Camunda, Conductor, Azure Durable Functions, Restate\n\n\n\n🔗\n\n**Related Terms**\nMicroservices, Event-Driven Architecture, Distributed Systems, Idempotency, Eventual Consistency.",
  "title": "Saga",
  "updatedAt": "2026-05-13T19:14:52.870Z"
}