Transações Distribuídas

A fã segurou o assento A-12 e toca em Pagar R$ 450. Agora três coisas precisam acontecer juntas: o inventory muda o assento de HELD para SOLD, o payment cobra o cartão por meio de um provedor externo e o order registra um pedido confirmado. Dentro de um único banco PostgreSQL isso seria uma única transação — BEGIN … COMMIT, tudo ou nada. Mas as três partes vivem em três serviços com três bancos de dados (e uma delas é de outra empresa). O que acontece quando a cobrança dá certo e o banco do inventory está fora do ar? Ou quando o assento é marcado SOLD e a cobrança é recusada?

Uma transação distribuída é uma unidade de trabalho que altera dados em vários nós e precisa ser atômica: ou todas as mudanças acontecem, ou nenhuma acontece. Esta página mostra o protocolo clássico que garante isso — o two-phase commit (2PC) —, por que ele raramente é usado entre microsserviços e o que o substitui na prática: sagas, o padrão de reserva (try–confirm–cancel) e o outbox transacional.

Atomicidade entre nós: o problema

Em um único nó, a atomicidade vem do log do banco de dados: as mudanças de uma transação se tornam duráveis e visíveis em um único ponto, o registro de commit. Entre nós não há um log único, e cada participante pode falhar de forma independente — então um ingênuo "faça commit em todos, um depois do outro" deixa uma janela em que alguns participantes fizeram commit e outros não:

sequenceDiagram
    participant O as order (checkout)
    participant I as banco do inventory
    participant P as provedor de pagamento
    O->>I: UPDATE do assento A-12 para SOLD, depois COMMIT
    I-->>O: commit feito
    O->>P: cobrar R$ 450
    P-->>O: recusado (limite do cartão)
    Note over O,P: o assento está SOLD mas ninguém pagou:<br/>nenhum lugar único consegue desfazer os dois

Existem duas famílias de soluções:

Two-phase commit (2PC)

O 2PC introduz um coordenador (muitas vezes o serviço ou o nó de banco que iniciou a transação) e divide o commit em duas fases¹:

1. Prepare (votação): o coordenador pergunta a cada participante "você consegue fazer commit?". Um participante que responde sim precisa antes gravar de forma durável em disco todas as mudanças e um registro de prepared, e manter os locks: a partir desse momento ele prometeu fazer commit se for pedido — não pode mais abortar por conta própria.
2. Commit (decisão): se todos votaram sim, o coordenador grava commit no próprio log e manda todos fazerem commit; se alguém votou não (ou estourou o timeout), ele decide abort.

sequenceDiagram
    participant C as coordenador
    participant I as banco do inventory
    participant R as banco do order
    C->>I: PREPARE (assento A-12 → SOLD)
    C->>R: PREPARE (pedido 981 → CONFIRMED)
    I-->>C: YES (mudanças + registro prepared em disco, locks mantidos)
    R-->>C: YES
    Note over C: todos YES: grava COMMIT no log do coordenador
    C->>I: COMMIT
    C->>R: COMMIT
    I-->>C: feito (locks liberados)
    R-->>C: feito

O PostgreSQL expõe o lado do participante como PREPARE TRANSACTION 'id' seguido, mais tarde, de COMMIT PREPARED 'id' ou ROLLBACK PREPARED 'id'; o padrão X/Open XA define o mesmo protocolo para bancos de dados e message brokers coordenados por um gerenciador de transações (como no Jakarta EE).

O problema do bloqueio

O ponto fraco é o momento depois que um participante votou sim e antes de ele ouvir a decisão. Se o coordenador cai ali, o participante fica em dúvida: não pode fazer commit (talvez alguém tenha votado não) e não pode abortar (talvez o coordenador tenha decidido commit e outros já tenham feito commit). Ele precisa esperar, segurando os locks, até o coordenador se recuperar:

sequenceDiagram
    participant C as coordenador
    participant I as banco do inventory
    participant R as banco do order
    C->>I: PREPARE
    C->>R: PREPARE
    I-->>C: YES (locks no assento A-12 mantidos)
    R-->>C: YES
    Note over C: cai antes de enviar a decisão
    Note over I: em dúvida: não pode fazer commit, não pode abortar
    Note over I,R: o assento A-12 fica travado até<br/>o coordenador voltar

Você mesmo pode provocar isso no simulador em Sagas: escolha 2PC e queda do coordenador.

Durante a abertura das vendas às 10:00, a linha travada de um assento bloqueia todos os outros fãs que tentam segurá-lo, e um coordenador que caiu pode congelar um bloco inteiro de assentos. O three-phase commit (3PC) tenta eliminar o bloqueio, mas pressupõe atrasos de rede limitados, que redes reais não garantem; sistemas em produção, em vez disso, tornam o próprio coordenador tolerante a falhas replicando sua decisão com consenso — exatamente o que fazem o Google Spanner (2PC sobre grupos Paxos) e o CockroachDB (sobre Raft)².

Quanto o 2PC custa

• Latência: duas idas e voltas a cada participante, mais gravações forçadas em disco (fsync) em cada prepare e na decisão. Os locks ficam presos durante todo o processo — o participante mais lento decide por quanto tempo.
• Disponibilidade: o coordenador e todos os participantes precisam estar no ar ao mesmo tempo. As disponibilidades se multiplicam, como serviços em série:

• Acoplamento: todo participante precisa falar o mesmo protocolo e expor um estado "prepared". Um provedor de pagamento externo nunca vai entrar no seu 2PC: a API dele cobra ou recusa, sem um passo de "prepare e espere minha decisão".

Sagas

Uma saga (Garcia-Molina e Salem, 1987)³ divide uma transação longa em uma sequência de transações locais \(T_1, T_2, …, T_n\), cada uma com commit no banco de dados do próprio serviço. Se o passo \(T_k\) falha, a saga executa transações de compensação \(C_{k-1}, …, C_1\) que desfazem semanticamente os passos já realizados. Não há lock global nem ponto de commit global.

O checkout do BoxOffice como uma saga:

Duas formas de coordenar os passos:

Sagas abrem mão do isolamento

Entre os passos, outras transações veem estados intermediários: um pedido PENDING, um assento RESERVED_FOR_PAYMENT. Sagas são ACD sem o I. Projete contramedidas explicitamente⁴:

• Locks semânticos: o estado intermediário é o lock — enquanto um assento está RESERVED_FOR_PAYMENT, nenhum outro fã consegue segurá-lo, e a reserva expira depois de 10 minutos se a saga nunca terminar.
• Passos comutativos e idempotentes: todo passo e toda compensação podem ser repetidos (at-least-once), então cada um precisa de uma chave de idempotência (Idempotência).
• Ordene os passos por risco: faça primeiro os passos baratos, invisíveis e fáceis de reverter, e por último os difíceis ou impossíveis de compensar (uma cobrança, um e-mail), de modo que uma falha no fim da saga tenha pouco a desfazer. Um estorno é uma compensação que o fã vê; liberar um assento é invisível.
• Passo pivô: o passo depois do qual a saga só pode seguir em frente (aqui, a cobrança bem-sucedida) — depois dele, os passos restantes precisam ser repetidos até darem certo, nunca compensados.

/** No @Transactional here: never hold a DB connection during a remote call. */
public OrderView pay(UUID id) {
    OrderView order = find(id).orElseThrow(() -> new ResponseStatusException(HttpStatus.NOT_FOUND));
    if (!"PENDING_PAYMENT".equals(order.status())) {
        return order; // already paid or cancelled: paying twice is a no-op
    }
    PaymentResponse payment = resilience
            ? payments.charge(order.id(), order.amount())
            : payments.chargeUnprotected(order.id(), order.amount());
    String next = "AUTHORIZED".equals(payment.status()) ? "CONFIRMED" : "CANCELLED";

    tx.executeWithoutResult(status -> {
        int changed = jdbc.sql("UPDATE orders SET status = ? WHERE id = ? AND status = 'PENDING_PAYMENT'")
                .params(next, id)
                .update();
        if (changed == 1) {
            String type = "CONFIRMED".equals(next) ? "OrderConfirmed" : "OrderCancelled";
            OrderEvent event = new OrderEvent(UUID.randomUUID(), type, order.id(), order.showId(),
                    order.holdId(), order.customerEmail(), order.amount(), Instant.now());
            outbox.append(event.eventId(), "order", order.id(), type, event);
        }
    });
    return find(id).orElseThrow();
}

Reserva: try, confirm, cancel

O padrão TCC (try–confirm–cancel) faz cada participante oferecer uma operação provisória com um timeout. O BoxOffice já funciona assim: o hold é o try (o assento fica reservado por 10 minutos), a venda é o confirm, e a expiração ou liberação é o cancel. Provedores de pagamento oferecem o mesmo formato: autorizar (reservar o valor) → capturar (efetivar a cobrança) ou cancelar (void, liberar o valor). Como todo estado provisório expira sozinho, uma queda em qualquer lugar deixa o sistema convergindo para um estado seguro em vez de bloquear.

O problema da escrita dupla e o outbox

Todo passo de uma saga faz duas coisas: altera o próprio banco de dados e avisa o próximo passo (envia um evento ou um comando). Fazer isso como duas escritas separadas é o problema da escrita dupla (dual write) — se o serviço cai entre elas, o banco diz "assento reservado", mas nenhum evento é enviado, e a saga trava:

sequenceDiagram
    participant I as inventory
    participant DB as banco do inventory
    participant K as Kafka
    I->>DB: UPDATE do assento + INSERT INTO outbox (SeatReserved), um COMMIT
    Note over I,DB: uma transação local: as duas ou nenhuma
    DB-->>I: commit feito
    Note over DB,K: um relay (poller ou CDC como o Debezium)<br/>lê a tabela de outbox
    DB->>K: publica SeatReserved
    K-->>DB: ack: marca a linha do outbox como enviada

O outbox transacional grava o evento em uma tabela outbox na mesma transação local que a mudança de negócio; um relay separado publica as linhas do outbox no broker e as marca como enviadas. A publicação é at-least-once, então os consumidores precisam ser idempotentes. Os detalhes (polling vs change data capture, ordenação, limpeza) estão em Mensageria — padrões e no Hands-on 7.

@Transactional
public PlaceResult place(OrderRequest req) {
    int inserted = jdbc.sql("""
            INSERT INTO orders (id, show_id, hold_id, customer_email, amount, status)
            VALUES (?, ?, ?, ?, ?, 'PENDING_PAYMENT')
            ON CONFLICT (hold_id) DO NOTHING
            """)
            .params(UUID.randomUUID(), req.showId(), req.holdId(), req.customerEmail(), req.amount())
            .update();

    OrderView order = jdbc.sql(SELECT + " WHERE hold_id = ?")
            .param(req.holdId())
            .query(OrderView.class)
            .single();

    if (inserted == 0) {
        // same hold already ordered: idempotent replay, no second event
        return new PlaceResult(order, false);
    }

    OrderEvent event = OrderEvent.placed(order);
    if (props.notifyMode() == NotifyMode.SYNC) {
        notifications.send(event); // BEFORE: the fan waits for the e-mail
    } else {
        outbox.append(event.eventId(), "order", order.id(), event.eventType(), event);
    }
    return new PlaceResult(order, true);
}

Escolhendo

Como se conecta

flowchart LR
    IDEM["chaves de idempotência<br/>(visão geral)"] --> SAGA["passos da saga<br/>repetidos com segurança"]
    OUT["outbox transacional"] --> SAGA
    SAGA --> ORCH["orquestração<br/>(motor de workflow)"]
    SAGA --> CHOR["coreografia<br/>(eventos no Kafka)"]
    TCC["reservas: hold, autorizar"] --> SAGA
    TPC["2PC"] --> BLOCK["bloqueia se o<br/>coordenador falha"]
    BLOCK --> CONS["replicar o coordenador<br/>→ Consenso"]
    CONS --> NEWSQL["dentro do Spanner,<br/>CockroachDB, transações do Kafka"]

Componentes da paleta envolvidos: stream / kafka (eventos da saga, relay do outbox) · queue (comandos aos participantes) · payment (autorizar / capturar / cancelar) · sql (transações locais + tabela de outbox) · worker (orquestrador, relay). Experimente os cenários payment-system e flash-sale no playground. Continua em: Mensageria — padrões, Compute — integrações, Estudo de caso: venda de ingressos.

Pontos-chave