{"post":{"slug":"saga-pattern-explained-2026","title":"Saga Pattern Explained in 2026: Distributed Transactions","excerpt":"A saga replaces one distributed transaction with a sequence of local transactions and compensating actions. Here is how orchestration and choreography manage failure across services.","category":"code","date":"August 9, 2026","author":"ByteLedger Team","content":"<span class=\"dropcap\">A</span> saga is a sequence of local transactions across multiple services, where each step commits its own database change and publishes an event or calls the next step directly, and every step has a matching compensating action that undoes it if a later step fails. Sagas exist because distributed two-phase commit does not scale across microservices — it requires every participant to hold locks until the slowest one responds, which turns a network partition into a system-wide outage. A saga trades that all-or-nothing atomicity for eventual consistency: the system passes through intermediate states, but a failure partway through is repaired by compensation rather than a global rollback.\n\n## How it works\n\nEach step in a saga is a normal local transaction against one service's own database. There is no distributed lock spanning services. If step three of five fails, the saga does not roll back the whole world — it runs compensating transactions for steps one and two, in reverse order, to bring the system back to a consistent state. A payment saga might look like: reserve inventory, charge payment, create shipment. If shipment creation fails, the compensations are refund payment and release inventory — new forward-moving transactions that semantically undo the earlier steps, not a magic rollback.\n\n## Orchestration vs choreography\n\nThere are two ways to coordinate the steps.\n\n| Approach | How it works | Strength | Weakness |\n| --- | --- | --- | --- |\n| Orchestration | A central coordinator tells each service what to do and calls compensations on failure | Saga logic lives in one place, easy to trace | Coordinator is a new component and a potential bottleneck |\n| Choreography | Each service publishes an event; the next service reacts to it with no central controller | No single point of control, services stay decoupled | Saga flow is implicit, scattered across services, harder to trace end-to-end |\n\nOrchestration tends to win as the number of steps grows, because having the sequence and compensation logic in one place — often built on a workflow engine like Temporal, AWS Step Functions, or Camunda — makes the saga's behavior auditable. Choreography fits smaller sagas of two or three steps where adding a coordinator would be more machinery than the flow warrants.\n\n## Common mistakes\n\n- **Treating compensations as an afterthought.** A compensating action is not automatic; someone has to write \"refund payment\" as its own real code path, including what happens if the refund itself fails. Design compensations at the same time as the forward steps, not after a production incident.\n- **Making saga steps non-idempotent.** Messages get redelivered. If \"charge payment\" runs twice because a retry fired after a slow response, the customer gets charged twice unless the step is written to be safe to run more than once with the same input.\n- **Skipping a dead-letter path.** When a step keeps failing and retries are exhausted, the saga needs an explicit terminal state — flagged for a human, not silently dropped or retried forever.\n- **Expecting saga to mean atomic.** A saga guarantees the system eventually reaches a consistent state, not that intermediate states are invisible. Any code path that reads mid-saga state needs to handle seeing a partially completed transaction.\n\n## FAQ\n\n**Is a saga the same as a distributed transaction?**\nNo. A saga replaces a single distributed transaction with a series of local ones plus compensations. It achieves eventual consistency, not the atomicity a real distributed transaction (like two-phase commit) provides.\n\n**Do I need a workflow engine to implement sagas?**\nNot for simple choreography-based sagas — a message queue and event handlers are enough. Once you have more than a handful of steps or need visibility into in-flight sagas, a workflow engine like Temporal or Step Functions earns its keep.\n\n**What happens if a compensating transaction fails?**\nThis is the hard case sagas do not solve for free. Compensations need their own retry logic, and a saga that cannot complete forward or backward should land in a dead-letter state for manual intervention rather than looping indefinitely.\n\n**When should I avoid the saga pattern entirely?**\nWhen all the state you need to change lives in one database. A single ACID transaction is simpler and gives you real atomicity — sagas are a workaround for state distributed across services, not a general-purpose transaction replacement.\n\n## Where to go next\n\nSagas are often paired with [CQRS](/blog/cqrs-vs-crud-2026) so the read side can show saga progress without querying every participating service directly. Each step in a saga should call downstream services defensively — see [the circuit breaker pattern](/blog/circuit-breaker-pattern-explained-2026) for how to stop one failing step from cascading into repeated timeouts. And if your saga's step handlers need to construct different downstream clients based on runtime config, [the factory pattern](/blog/factory-pattern-explained-2026) is the standard way to keep that decision logic in one place.","hue":318,"metaTitle":"Saga Pattern Explained 2026: Distributed Transactions","metaDescription":"Saga pattern explained for 2026 — orchestration vs choreography, compensating transactions, and managing distributed transactions across microservices.","keywords":["saga pattern 2026","saga pattern explained","distributed transactions microservices","orchestration vs choreography saga","compensating transaction pattern","saga pattern vs two phase commit","microservices transaction management"],"tldr":["**Sagas replace one distributed transaction with several local ones** — each step commits its own database change and has a compensating action to undo it if a later step fails.","**Orchestration centralizes the sequence, choreography distributes it** — orchestration is easier to trace as steps grow; choreography avoids a coordinator for small flows.","**Compensations are real code, not automatic rollbacks** — someone has to write \"refund payment\" and handle what happens if the refund itself fails.","**Saga steps must be idempotent** — redelivered messages will re-run a step, and a non-idempotent charge or reservation will double up.","**Skip:** building sagas for state that lives in one database — a single ACID transaction is simpler and gives you real atomicity a saga cannot."],"readTime":"4 min read","wordCount":809},"related":[{"slug":"what-is-a-saga-pattern-2026","title":"What Is the Saga Pattern in 2026: Distributed Transactions","excerpt":"The saga pattern breaks a distributed transaction into local steps, each with a compensating action if a later step fails. Here is the 2026 guide to orchestration, choreography, and when sagas beat two-phase commit.","category":"code","date":"July 20, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":280},{"slug":"distributed-transactions-microservices-2026","title":"Distributed Transactions in Microservices: 2026 Guide","excerpt":"Splitting a system into services means splitting its data too, so an atomic commit is no longer free. Here is how to choose between blocking coordination, compensation, and event-driven design.","category":"code","date":"July 31, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":304},{"slug":"two-phase-commit-explained-2026","title":"Two-Phase Commit Explained in 2026: Why Teams Avoid It","excerpt":"Two-phase commit guarantees atomicity across databases by holding every participant's locks until all of them agree. Here is how it works and why that guarantee is exactly what makes teams avoid it.","category":"code","date":"August 10, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":306}],"sameCategory":[{"slug":"bazel-build-explained-2026","title":"Bazel Explained: What Hermetic Builds Actually Cost","excerpt":"Bazel delivers reproducible, precisely cached builds and demands that you describe everything. Here is what you get, what it costs, and who should say no.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":145},{"slug":"graphql-federation-2026","title":"GraphQL Federation: One Graph, Many Teams","excerpt":"Federation composes independently-owned subgraphs into a single API. Here is what it solves, the operational cost it adds, and when a simpler gateway is enough.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":300},{"slug":"hermetic-builds-explained-2026","title":"Hermetic Builds Explained: Same Inputs, Same Output","excerpt":"A hermetic build depends only on declared inputs. Here is what that property gives you, the common leaks that break it, and how to move toward it incrementally.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":130},{"slug":"monorepo-tooling-compared-2026","title":"Monorepo Tooling Compared: What You Actually Need","excerpt":"Monorepo tools solve task orchestration and caching, not repository layout. Here is what each tier provides and how to tell when you have outgrown the simple option.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":150}],"newer":{"slug":"running-llms-locally-guide-2026","title":"Running LLMs Locally: A Step-by-Step Guide 2026","excerpt":"Running an LLM locally comes down to six steps: size your hardware, pick a quantization level, install a runtime, pull a model, connect it to your tools, and benchmark. Here is the concrete 2026 walkthrough.","category":"ai","date":"August 9, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":204},"older":{"slug":"secured-vs-unsecured-credit-card-2026","title":"Secured vs Unsecured Credit Card for Rebuilding","excerpt":"Rebuilding credit usually comes down to a secured card, which needs a refundable deposit but approves almost anyone, or an unsecured starter card, which costs more but skips the deposit. Here is how to choose.","category":"finance","date":"August 9, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":295}}