0Pricing
System Design Basics for Backend Developers · Aula

O Padrão Saga para Transações Distribuídas

Aprenda a manter a consistência dos dados entre microsserviços sem usar transações distribuídas, aplicando o padrão Saga com coreografia e orquestração.

O Padrão Saga para Transações Distribuídas é uma aula grátis de System Design Basics for Backend Developers no CoddyKit. Esta é a aula 4 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de System Design Basics for Backend Developers, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de System Design Basics for Backend Developers inclui 4 aulas no total.

Partes desta aula ainda não foram traduzidas e aparecem em inglês.

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

Perguntas Frequentes

A aula “O Padrão Saga para Transações Distribuídas” é grátis?

Sim — o texto completo de “O Padrão Saga para Transações Distribuídas” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de System Design Basics for Backend Developers, atualize para CoddyKit PRO. O curso de System Design Basics for Backend Developers inclui 4 aulas no total.

O que vou aprender em “O Padrão Saga para Transações Distribuídas”?

Aprenda a manter a consistência dos dados entre microsserviços sem usar transações distribuídas, aplicando o padrão Saga com coreografia e orquestração. Você pratica System Design Basics for Backend Developers com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.

Preciso ter experiência prévia para começar System Design Basics for Backend Developers?

Nenhuma experiência prévia é necessária. System Design Basics for Backend Developers no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 4 de 4.

Quanto tempo leva a aula “O Padrão Saga para Transações Distribuídas”?

A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.

Posso escrever e executar código nesta aula de System Design Basics for Backend Developers?

Sim. Cada aula de System Design Basics for Backend Developers inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.

Todas as aulas deste curso

  1. Decomposição de monólitos
  2. Descoberta e registro de serviços
  3. Padrões de comunicação entre serviços
  4. O Padrão Saga para Transações Distribuídas
← Voltar para System Design Basics for Backend Developers