Saga [pattern] v1.0.0

When a business transaction must update data in multiple services, you cannot use a single ACID transaction across them (no distributed XA). A Saga decomposes the work into a sequence of local transactions, each in one service. If a step fails, prior steps are undone with explicit compensating transactions.

Label

Saga — distributed transaction as a sequence of local transactions

Problem

A single business transaction (Place Order) spans Order Service, Inventory Service, and Payment Service. Each owns its own database — there is no two-phase commit available. Naively committing each step leaves the system inconsistent on partial failure.

Solution

    Decompose into a chain of local transactions plus compensating transactions:

      1. Order Service       — create order (status: PENDING)
      2. Inventory Service   — reserve items
      3. Payment Service     — charge card
      4. Order Service       — confirm order (status: CONFIRMED)

    If step 3 fails:
      3'. Inventory Service  — release reservation (compensating)
      2'. Order Service      — cancel order (compensating)

    Coordination is either:
      - Choreography: each service emits events; others react.
      - Orchestration: a saga orchestrator drives the steps and reacts to failures.
  

Saga [pattern] v1.0.0

When a business transaction must update data in multiple services, you cannot use a single ACID transaction across them (no distributed XA). A Saga decomposes the work into a sequence of local transactions, each in one service. If a step fails, prior steps are undone with explicit compensating transactions.

Label

Saga — distributed transaction as a sequence of local transactions

Problem

A single business transaction (Place Order) spans Order Service, Inventory Service, and Payment Service. Each owns its own database — there is no two-phase commit available. Naively committing each step leaves the system inconsistent on partial failure.

Solution

    Decompose into a chain of local transactions plus compensating transactions:

      1. Order Service       — create order (status: PENDING)
      2. Inventory Service   — reserve items
      3. Payment Service     — charge card
      4. Order Service       — confirm order (status: CONFIRMED)

    If step 3 fails:
      3'. Inventory Service  — release reservation (compensating)
      2'. Order Service      — cancel order (compensating)

    Coordination is either:
      - Choreography: each service emits events; others react.
      - Orchestration: a saga orchestrator drives the steps and reacts to failures.
  

Relations

requires: [@backend-architecture/pattern-database-per-service]

Label

Saga — distributed transaction as a sequence of local transactions

Problem

A single business transaction (Place Order) spans Order Service, Inventory Service, and Payment Service. Each owns its own database — there is no two-phase commit available. Naively committing each step leaves the system inconsistent on partial failure.

Solution

    Decompose into a chain of local transactions plus compensating transactions:

      1. Order Service       — create order (status: PENDING)
      2. Inventory Service   — reserve items
      3. Payment Service     — charge card
      4. Order Service       — confirm order (status: CONFIRMED)

    If step 3 fails:
      3'. Inventory Service  — release reservation (compensating)
      2'. Order Service      — cancel order (compensating)

    Coordination is either:
      - Choreography: each service emits events; others react.
      - Orchestration: a saga orchestrator drives the steps and reacts to failures.
  

Requires

• @backend-architecture/pattern-database-per-service