Exactly-once Quase Nunca Existe, Como Pensar Direito Sobre Isso

O problema

Tem frase que fica bonita em diagrama e decepciona em sistema real.

Exactly-once e uma delas.

Muita gente ouve isso e imagina um mundo limpo:

• a mensagem chega uma vez
• o consumidor processa uma vez
• o efeito acontece uma vez

Na prática, cada uma dessas etapas pode falhar em momento diferente.

E e justamente por isso que a promessa de “uma vez só” costuma ser bem mais estreita do que parece.

Modelo mental

Antes de discutir exactly-once, separe tres perguntas:

1. A entrega da mensagem acontece uma vez só?
2. O processamento do consumidor roda uma vez só?
3. O efeito final no negócio acontece uma vez só?

Essas tres coisas não sao automaticamente iguais.

Na maior parte dos sistemas reais, o objetivo mais honesto e este:

aceitar que repetição pode acontecer e desenhar o sistema para que o efeito final continue correto.

Quebrando o problema

Por que duplicidade aparece

Mensagem repetida pode aparecer porque:

• o consumidor processou, mas caiu antes de confirmar
• houve timeout na confirmação
• o produtor repetiu por inseguranca
• a infraestrutura opera com entrega at-least-once

Nada disso e exótico.

E comportamento normal de ambiente distribuido.

Onde a fantasia quebra

Imagine que o consumidor recebeu a mensagem, gravou no banco e caiu antes de mandar ack.

Do ponto de vista da fila, aquela mensagem talvez precise voltar.

Do ponto de vista do banco, o efeito talvez já tenha acontecido.

Aqui você entende por que “entregou uma vez” e “aplicou uma vez” não sao a mesma conversa.

O alvo prático costuma ser efeito seguro

Se o sistema consegue reconhecer que aquela intenção já foi aplicada, ele pode receber repetição sem cobrar, reservar ou registrar duas vezes.

Esse desenho costuma usar combinações como:

• idempotency key
• tabela de eventos processados
• operação atomica com registro de deduplicação
• outbox/inbox pattern em cenarios mais acoplados

Claims de exactly-once precisam de leitura cuidadosa

Algumas tecnologias oferecem algo chamado exactly-once, mas quase sempre dentro de um recorte específico.

Por exemplo:

• dentro de certo broker
• entre certas etapas de stream processing
• sob determinadas garantias de transação

Isso não significa automaticamente exactly-once de ponta a ponta para o efeito de negócio inteiro.

Exemplo simples

Imagine um evento order_paid.

O consumidor recebe esse evento e precisa:

• marcar pedido como pago
• emitir nota
• disparar email

Se o processo cai no meio, a mensagem pode reaparecer.

Se o sistema não tiver deduplicação e idempotencia, você pode:

• emitir nota duas vezes
• mandar email duplicado
• registrar transição repetida

Um desenho melhor seria registrar o event_id dentro da mesma unidade de corretude da operação importante.

Se aquele event_id já foi aplicado, o reprocessamento não causa dano novo.

Talvez a mensagem tenha chegado mais de uma vez.

Mas o efeito final relevante continua uma vez só.

Erros comuns

• Pedir exactly-once sem definir onde a garantia deveria valer.
• Tratar transporte, processamento e efeito de negócio como se fossem a mesma camada.
• Achar que broker “forte” elimina necessidade de idempotencia.
• Confiar em retry sem plano para repetição.
• Vender garantia absoluta para problema que só precisa de efeito final seguro.

Como um senior pensa

Quem tem mais experiência costuma desconfiar de palavras bonitas cedo.

O raciocínio geralmente vai por aqui:

“Eu não preciso de pureza teorica em toda a jornada. Eu preciso garantir que repetição não gere dano real no negócio.”

Isso traz a conversa para o lugar certo.

Menos marketing de garantia. Mais desenho de corretude.

O que o entrevistador quer ver

Em entrevista, esse tema costuma separar bem quem decorou termo de quem entende sistema distribuido de verdade.

O avaliador quer ver se você:

• reconhece repetição como comportamento normal
• separa camada de entrega de efeito final
• sugere idempotencia e deduplicação
• evita prometer exactly-once como se fosse checkbox simples

Uma resposta forte costuma soar assim:

“Na prática, eu assumo at-least-once e desenho o consumidor para aguentar repetição sem dano. O que me importa e efeito final correto, não fantasia de transporte perfeito.”

Exactly-once vende tranquilidade. Idempotencia e deduplicação entregam mais resultado no mundo real.