Saga — A Worked Orchestration Example

From definition to a real flow

You’ve seen what a Saga is (2PC vs Saga vs TCC): a sequence of local transactions, each with a compensating transaction that undoes it if a later step fails. Let’s walk a concrete orchestration — a central coordinator drives the steps.

The flow: place an order

  Orchestrator drives 3 local transactions, each in its own service/DB:

   1. Order Service     → CREATE order (status=PENDING)     compensate: CANCEL order
   2. Inventory Service → RESERVE items                     compensate: RELEASE items
   3. Payment Service   → CHARGE card                       compensate: REFUND

  Happy path:  1 → 2 → 3 → mark order CONFIRMED
  Payment fails at step 3:  run compensations in REVERSE → RELEASE items → CANCEL order

Orchestrator logic (pseudocode)

 placeOrderSaga(cart):
   order = orderSvc.create(cart)            # step 1
   try:
       inventorySvc.reserve(order)          # step 2
       try:
           paymentSvc.charge(order)         # step 3
       except PaymentError:
           inventorySvc.release(order)      # compensate 2
           orderSvc.cancel(order)           # compensate 1
           return FAILED
   except InventoryError:
       orderSvc.cancel(order)               # compensate 1
       return FAILED
   orderSvc.confirm(order); return OK

What makes it correct

• Each step commits locally (no distributed lock) — so it scales, unlike 2PC.
• Compensations run in reverse order and must be idempotent (a retry of “release items” mustn’t double-release).
• Between steps the system is in a visible intermediate state (order PENDING) — design for it; this is eventual consistency, not isolation.

Takeaways

• A Saga = forward local transactions + reverse compensations on failure.
• Orchestration (central driver, shown here) is easier to reason about than choreography (services reacting to events) for complex flows.
• The events that trigger each step should be emitted reliably via the Transactional Outbox.

---

Re-authored from-scratch for this guide. Diagrams adapted from Karan Pratap Singh’s System Design (MIT); patterns follow Azure Architecture Center / microservices.io / DDIA conventions.

I just read a lesson on **Saga — A Worked Orchestration Example** (System Design) and want to truly understand it. Explain Saga — A Worked Orchestration Example from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Teach me **Saga — A Worked Orchestration Example** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Quiz me on **Saga — A Worked Orchestration Example** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Help me remember **Saga — A Worked Orchestration Example** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.