System Design Basics for Backend Developers · Lezione

Il pattern Saga per le transazioni distribuite

Impari a mantenere la coerenza dei dati tra microservizi senza transazioni distribuite, usando il pattern Saga con coordinamento tramite choreography e orchestration.

Lezione 4 di 413 passaggi

Il pattern Saga per le transazioni distribuite è una lezione System Design Basics for Backend Developers gratuita su CoddyKit. Questa è la lezione 4 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento System Design Basics for Backend Developers, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso System Design Basics for Backend Developers include 4 lezioni in totale.

Parti di questa lezione non sono ancora state tradotte e vengono mostrate in inglese.

The Distributed Transaction Problem

In a monolith, one database transaction can update everything atomically. In microservices, each service owns its own database, so a single classic transaction across them is impractical.

How do you keep data consistent when an operation spans multiple services?

Why Not Two-Phase Commit?

Two-phase commit (2PC) can coordinate a distributed transaction, but it locks resources across services and blocks if the coordinator fails. It scales poorly and hurts availability — usually the wrong fit for microservices.

Enter the Saga

A Saga breaks a business transaction into a sequence of local transactions, one per service. Each step publishes an event or sends a command to trigger the next.

There is no global lock — consistency is achieved over time.

Compensating Transactions

If a later step fails, the saga cannot roll back like a database. Instead it runs compensating transactions that semantically undo the earlier steps.

  • Order placed -> compensate by cancelling order
  • Payment charged -> compensate by refunding

An Order Saga

Consider placing an order: reserve inventory, charge payment, schedule shipping. If payment fails, you compensate by releasing the inventory.

steps = ['reserve_inventory', 'charge_payment', 'schedule_shipping']
compensations = ['release_inventory', 'refund_payment', 'cancel_shipping']

done = []
for i, step in enumerate(steps):
    ok = step != 'charge_payment'
    if not ok:
        print('FAILED at', step)
        for j in reversed(range(len(done))):
            print('compensate:', compensations[j])
        break
    done.append(step)
    print('ok:', step)

Choreography

In choreography, there is no central coordinator. Each service listens for events and reacts by doing its work and emitting the next event. It is decentralized and loosely coupled.

OrderCreated -> (Inventory) -> InventoryReserved
InventoryReserved -> (Payment) -> PaymentCharged
PaymentCharged -> (Shipping) -> OrderShipped

Choreography Trade-offs

Choreography is simple for short flows but the overall logic is scattered across services. With many steps it becomes hard to understand and risks cyclic event dependencies.

Orchestration

In orchestration, a central orchestrator tells each service what to do and tracks progress. The workflow lives in one place, making complex sagas easier to reason about and monitor.

Orchestrator:
  -> Inventory.reserve()
  -> Payment.charge()
  -> Shipping.schedule()
  on failure -> run compensations in reverse

Idempotency Is Mandatory

Messages can be delivered more than once, so every saga step and compensation must be idempotent. Use an idempotency key so re-processing the same message has no extra effect.

Eventual Consistency

Sagas give eventual consistency, not immediate. There is a window where the system is partially updated. Design the UI and business rules to tolerate this — for example, an order shown as PENDING until confirmed.

Choosing an Approach

Use choreography for simple flows with few participants, and orchestration when the workflow is complex or needs central visibility. Either way, make steps idempotent and define a compensation for every action.

Quick Check

Test your understanding of the Saga pattern.

Recap

You learned how microservices stay consistent without distributed transactions:

  • Sagas chain local transactions with compensations for failures
  • Choreography is decentralized; orchestration is centralized
  • Steps must be idempotent against duplicate delivery
  • The result is eventual consistency, which the design must tolerate
Gratis per iniziare

Impara System Design Basics for Backend Developers con un tutor IA — gratis

Scrivi ed esegui vero codice nel tuo browser, ricevi aiuto istantaneo da un tutor IA disponibile 24/7, e riprendi da dove hai lasciato sul web o nell'app.

Corsi
12
Lezioni
48

Domande Frequenti

La lezione «Il pattern Saga per le transazioni distribuite» è gratuita?

Sì — il testo completo di «Il pattern Saga per le transazioni distribuite» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso System Design Basics for Backend Developers, passa a CoddyKit PRO. Il corso System Design Basics for Backend Developers include 4 lezioni in totale.

Cosa imparerò in «Il pattern Saga per le transazioni distribuite»?

Impari a mantenere la coerenza dei dati tra microservizi senza transazioni distribuite, usando il pattern Saga con coordinamento tramite choreography e orchestration. Eserciti System Design Basics for Backend Developers con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare System Design Basics for Backend Developers?

Non è richiesta alcuna esperienza precedente. System Design Basics for Backend Developers su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 4 di 4.

Quanto tempo richiede la lezione «Il pattern Saga per le transazioni distribuite»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione System Design Basics for Backend Developers?

Sì. Ogni lezione System Design Basics for Backend Developers include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

  1. Scomposizione dei monoliti
  2. Service discovery e registry
  3. Pattern di comunicazione tra servizi
  4. Il pattern Saga per le transazioni distribuite
← Torna a System Design Basics for Backend Developers