Outbox e inbox sem transformar todo fluxo em event sourcing

O problema

Um problema clássico de backend é este:

• o banco confirma
• a publicação do evento falha

Agora o estado local mudou, mas o resto do sistema não ficou sabendo.

Outbox nasce para fechar exatamente essa brecha.

Inbox costuma entrar do outro lado:

• mensagem chega
• pode chegar de novo
• consumidor precisa tratar repetição como normal

O problema é que muita equipe vai de um extremo ao outro:

• ou ignora isso completamente
• ou decide que todo fluxo precisa do mesmo maquinário

Modelo mental

Outbox e inbox não são filosofia.

São padrões operacionais para duas perguntas bem concretas:

• como eu propago um fato depois do commit sem perder esse fato no meio?
• como eu consumo esse fato sem duplicar efeito quando houver reentrega?

Só isso já resolve muita coisa.

Não precisa puxar, por tabela:

• event sourcing
• saga para tudo
• barramento heroico

O que o outbox realmente resolve

Outbox normalmente resolve:

• commit local bem-sucedido
• publicação externa reprocessável

Em vez de:

• gravar pedido
• publicar evento “na esperança”

o sistema faz:

• grava pedido
• grava registro no outbox na mesma transação local
• processo separado publica depois

Se a publicação falhar, ainda existe rastro persistido do que precisa sair.

O que o inbox realmente resolve

Inbox ajuda o consumidor a registrar:

• recebi esta mensagem
• já apliquei ou não apliquei esse efeito

Isso reduz o drama em cenários normais de:

• reentrega
• retry
• restart de worker

Na prática, inbox costuma andar junto com idempotência.

Sem isso, o consumidor continua vulnerável a efeito duplicado.

Exemplo simples

Imagine order_paid.

No produtor:

• banco marca pedido como pago
• mesma transação grava evento no outbox

No consumidor:

• chega order_paid
• inbox registra que aquela mensagem já foi vista
• comissão é liberada só uma vez

Esse desenho não promete mágica.

Ele só torna o fluxo mais honesto e reprocessável.

O erro comum

O erro comum é usar outbox/inbox como martelo universal.

Nem todo fluxo precisa disso.

Se um side effect é:

• opcional
• barato
• facilmente recalculável
• sem impacto crítico se atrasar ou repetir

talvez a infraestrutura extra não pague a conta.

Padrão bom continua sendo custo.

Não decoração arquitetural.

Como um senior pensa

Quem decide melhor costuma perguntar:

• qual inconsistência real eu estou tentando evitar?
• se a publicação falhar, o que eu perco de verdade?
• se a mensagem repetir, qual efeito pode duplicar?
• este fluxo merece essa complexidade operacional?

Essa conversa geralmente separa sistema sólido de sistema performático.

Ângulo de entrevista

Esse tema aparece em backend, filas, integração entre serviços e system design.

O entrevistador quer ver se você sabe:

• por que publicar “depois do commit” pode perder evento
• por que consumidor precisa tratar reentrega como normal
• quando o padrão vale a pena e quando é excesso

Resposta forte costuma soar assim:

“Eu usaria outbox quando preciso garantir propagação confiável depois do commit local, e inbox quando o consumidor precisa absorver reentrega sem duplicar efeito. Isso não significa transformar todo fluxo em event sourcing; significa usar o padrão só onde a brecha realmente dói.”

Takeaway direto

Outbox e inbox são ótimos quando resolvem um problema claro.

Quando viram reflexo automático, começam a criar outro.