Saga Pattern Architecture Diagram: Choreography vs. Orchestration (2026)

How to create saga pattern architecture diagrams for distributed transactions in microservices. Covers choreography vs. orchestration, compensating transactions, Temporal, and AWS Step Functions — with AI prompt templates.

Ryan·Senior AI Engineer

·Last updated June 7, 2026

The saga pattern is a distributed transaction management technique for microservices architectures where each service has its own database and traditional ACID transactions that span services are not possible. A saga breaks a distributed transaction into a sequence of local transactions, each executed by a single service. If one step fails, compensating transactions undo the preceding steps to maintain data consistency. A saga pattern architecture diagram makes the transaction flow, failure paths, and compensation logic visible — which is critical for design reviews, on-call runbooks, and system design interview preparation.

This guide covers the two saga implementations (choreography and orchestration), how to diagram compensating transactions, and prompt templates for generating accurate saga diagrams with AI.

Why ACID transactions fail in microservices

In a monolith with a single shared database, a multi-step operation (reserve inventory → charge payment → create order → send confirmation) can be wrapped in a database transaction: if any step fails, everything rolls back atomically. In microservices, each service owns its own database — a payment service has its Stripe account and its own Postgres, an inventory service has its Redis and Postgres. There is no single transaction coordinator that spans all these resources. The saga pattern replaces the database transaction with a sequence of local transactions and explicit compensating actions.

Saga implementation 1: Choreography

In a choreography-based saga, there is no central coordinator. Each service listens for domain events published by other services and reacts by executing its local transaction and publishing its own event. The saga progresses through event chains.

Advantages: No single point of failure, loose coupling between services, easy to add new participants without changing existing ones.

Disadvantages: The overall transaction flow is implicit and distributed across multiple services — it's harder to debug, monitor, and reason about. Adding observability (distributed tracing across event chains) is required.

"A choreography-based order placement saga using Kafka: 1) Order Service creates an order in PENDING state and publishes 'OrderCreated' event. 2) Inventory Service listens for 'OrderCreated', reserves stock, and publishes 'InventoryReserved' (success) or 'InventoryFailed' (failure). 3) Payment Service listens for 'InventoryReserved', charges the customer, and publishes 'PaymentCompleted' or 'PaymentFailed'. 4) Order Service listens for 'PaymentCompleted' and updates order to CONFIRMED state, then publishes 'OrderConfirmed' for the Notification Service. On failure: if 'PaymentFailed', Inventory Service listens and releases the reservation (compensating transaction). Show all topics and events on the diagram."

Saga implementation 2: Orchestration

In an orchestration-based saga, a central orchestrator service coordinates the transaction by calling each participant service in sequence (via commands) and deciding what to do based on each service's response. The orchestrator contains the entire saga logic in one place.

Advantages: The transaction flow is explicit and centralized — easy to understand, test, and debug. The saga state is visible in the orchestrator.

Disadvantages: The orchestrator is a new service that must be maintained and can become a bottleneck. Tight coupling between orchestrator and participants.

"An orchestration-based order saga using Temporal workflows: the Order Orchestrator Workflow coordinates the saga. Step 1: calls Inventory Service activity 'ReserveInventory' — on success, proceeds to step 2; on failure, marks order FAILED (no compensation needed, nothing charged yet). Step 2: calls Payment Service activity 'ChargePayment' — on success, proceeds to step 3; on failure, calls compensating activity 'ReleaseInventoryReservation', then marks order FAILED. Step 3: calls Fulfillment Service activity 'CreateShipment' — on success, marks order CONFIRMED; on failure, calls 'RefundPayment' and 'ReleaseInventoryReservation', then marks order FAILED. Temporal handles retries, timeouts, and durable state persistence. Show the workflow decision tree and compensating activities."

Compensating transactions: the rollback diagram

Each step in a saga must have a corresponding compensating transaction that undoes its effects. Unlike database rollbacks (which are atomic and automatic), compensating transactions are application-level operations that must be designed, implemented, and explicitly triggered. Show the compensation path as a separate flow on the diagram — usually a dashed or red arrow returning from the failure point back through previous steps.

"Show the failure and compensation path for the order placement saga: the normal happy path flows top to bottom (Order Created → Inventory Reserved → Payment Charged → Shipment Created → Order Confirmed). Add a failure branch at the Payment step: PaymentFailed triggers a compensating flow (dashed red arrows) that calls ReleaseInventoryReservation and then sets the order to CANCELLED state. Add another failure branch at the Shipment step: ShipmentFailed triggers RefundPayment and ReleaseInventoryReservation compensating transactions before CANCELLED state. Annotate each compensating action with its expected latency and idempotency guarantee."

Saga pattern: choreography vs. orchestration comparison

Dimension	Choreography	Orchestration
Coupling	Event schema coupling only	Orchestrator coupled to all participants
Visibility	Distributed, implicit flow	Centralized, explicit flow
Debugging	Hard — requires distributed tracing	Easy — saga state in one place
Adding participants	Easy — subscribe to existing events	Requires orchestrator change
Compensation logic	Distributed across services	Centralized in orchestrator
Common tools	Kafka, RabbitMQ, EventBridge	Temporal, AWS Step Functions, Conductor

Saga pattern with AWS Step Functions

"An order fulfillment saga using AWS Step Functions (Standard Workflow for durability): the state machine has five states — ReserveInventory (calls Inventory Lambda), ProcessPayment (calls Payment Lambda), CreateShipment (calls Fulfillment Lambda), SendConfirmation (calls Notification Lambda), OrderComplete. Each Lambda task has a Catch block: on failure, Step Functions transitions to a compensating Parallel state that concurrently runs ReleaseInventory and RefundPayment Lambdas. The state machine ARN is stored in the Orders DynamoDB table for tracking. CloudWatch metrics alert if any execution enters the FAILED state. Show the state machine as a flowchart with branching compensation paths."

What to annotate on a saga diagram

Happy path vs. compensation path: Use distinct visual styles (solid lines for the normal flow, dashed red lines for compensation) — these are the two different behaviors the system exhibits and must be legible at a glance
Idempotency guarantee: Annotate each step with whether it is idempotent — saga steps may be retried by the framework (Temporal, Step Functions), and non-idempotent operations (like charging a card) require deduplication logic
Saga state persistence: Show where the saga execution state is stored (Temporal's event history, Step Functions execution state, or a saga_executions table in your database) — this determines durability on crash
Timeout behavior: Label each step with its timeout and what happens on timeout — treat timeout as a failure that triggers the compensation path
Which services participate: Number the steps in the saga flow (1, 2, 3...) and align them with the compensating actions in reverse order (3c, 2c, 1c) — this makes the rollback sequence explicit

Ready to try it yourself?

Start Creating - Free