0Pricing
System Design Basics for Backend Developers · Leçon

Le modèle Saga pour les transactions distribuées

Apprenez à maintenir la cohérence des données entre microservices sans transactions distribuées, en utilisant le modèle Saga avec chorégraphie et orchestration.

Le modèle Saga pour les transactions distribuées est une leçon System Design Basics for Backend Developers gratuite sur CoddyKit. Ceci est la leçon 4 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage System Design Basics for Backend Developers, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours System Design Basics for Backend Developers comprend 4 leçons au total.

Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.

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

Questions Fréquemment Posées

La leçon « Le modèle Saga pour les transactions distribuées » est-elle gratuite ?

Oui — le texte complet de « Le modèle Saga pour les transactions distribuées » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours System Design Basics for Backend Developers, passe à CoddyKit PRO. Le cours System Design Basics for Backend Developers comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Le modèle Saga pour les transactions distribuées » ?

Apprenez à maintenir la cohérence des données entre microservices sans transactions distribuées, en utilisant le modèle Saga avec chorégraphie et orchestration. Tu pratiques System Design Basics for Backend Developers avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer System Design Basics for Backend Developers ?

Aucune expérience préalable n'est requise. System Design Basics for Backend Developers sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 4 sur 4.

Combien de temps prend la leçon « Le modèle Saga pour les transactions distribuées » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon System Design Basics for Backend Developers ?

Oui. Chaque leçon System Design Basics for Backend Developers inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. Décomposition des monolithes
  2. Découverte et registre des services
  3. Modèles de communication interservices
  4. Le modèle Saga pour les transactions distribuées
← Retour à System Design Basics for Backend Developers