Manter vários sistemas de acordo quando um deles cai

Exigir a mesma transação para o pedido e o evento decide se um processo caído deixa o banco e a fila combinando ou brigando entre si. Quando um pedido toca banco, fila e parceiro, nenhum deles enxerga o todo, e as três exigências a seguir evitam estado inconsistente.

O defeito clássico tem nome: escrita dupla. O serviço grava o pedido no banco e publica o evento na fila, em dois passos que não compartilham a mesma transação.

Se o processo cai entre um e outro, o pedido existe e o evento não, ou o contrário. Ninguém percebe no dia, porque cada sistema, olhado sozinho, parece correto.

A saída é gravar o evento numa tabela do próprio banco, dentro da mesma transação do pedido. Um processo separado lê essa tabela e publica na fila, com nova tentativa. É o padrão outbox, que é a caixa de saída do serviço.

O relay pode publicar duas vezes, e isso é aceitável. A deduplicação continua com o consumidor, pela chave de idempotência da aula anterior.

Quando o passo já foi confirmado em outro sistema, desfazer deixa de ser automático. A saga é a sequência com um caminho de volta escrito à mão: para cada passo, a operação de negócio que o compensa.

Outra abordagem é a execução durável, que já existia antes de 2026. A fila resolve desacoplamento, ou seja, quem chama para de esperar, mas não guarda o ponto em que a rotina parou.

A nova tentativa recomeça do zero e paga de novo pelo trabalho já feito. A execução durável resolve retomada, isto é, a tarefa continua do ponto onde parou.

Essa categoria cresceu com o agente de IA que roda por minutos, onde falhar no meio significa pagar duas vezes pelos mesmos tokens. Trigger.dev, Inngest e Vercel Workflow disputam esse espaço desde a versão 4.5.0, de julho de 2026.

Na maioria dos contratos de integração falta a cláusula do desfazer. Ela diz quem cancela, em quanto tempo e com qual prova. Sem ela, cada estorno vira negociação por e-mail entre dois times que não se conhecem.

Peça esse texto durante a negociação, antes da assinatura. Peça também o desenho de um fluxo que cruza dois sistemas, com o ponto em que o evento é gravado. Para cada confirmação em outro sistema, peça a operação que a compensa e quem autoriza.

Separe o que precisa retomar do que basta repetir: tarefa longa e cara pede execução durável, e trabalho curto e barato aceita recomeçar do zero. Aceitar que a fila é confiável não basta como resposta, porque a falha mora entre o passo gravado e o passo publicado, não dentro de cada um deles isolado.

Fila é a lista de trabalhos aceitos agora e executados depois, fora da espera do cliente. Idempotência é a propriedade de receber a mesma ordem duas vezes e cobrar uma vez só. Backoff é a espera crescente entre tentativas, limitada por uma política.

Depois de esgotar as tentativas, o trabalho cai na fila morta, o depósito do que falhou até o fim. Execução durável é a tarefa que retoma do ponto onde parou depois de queda, desconexão ou nova publicação.

Duas coisas não saem da sua mesa, e são a decisão que cabe a você. A primeira é a pergunta de aceite de todo fluxo com dinheiro: o que acontece se a mesma mensagem chegar três vezes. Aprove a resposta que mostra uma chave única gravada junto da cobrança.

A segunda é quando dividir o sistema em serviços separados, o que chega no dia em que o módulo tem carga, ciclo de entrega e time próprios. O time escolhe a tecnologia de fila. Peça por escrito o painel da fila morta, com dono e prazo, e confira se nenhum item passa do prazo sem alguém responder.