Dual-Write Problem

O problema de dual-write acontece quando um sistema tenta persistir a mesma mudanca em dois sistemas diferentes ao mesmo tempo, por exemplo:

Por que isso acontece

Nao existe transacao ACID entre banco e broker de forma confiavel em sistemas distribuidos.

BEGIN TRANSACTION
  write DB
  publish event
COMMIT

Entre as operacoes podem acontecer falha de rede, timeout, crash da aplicacao e retries duplicados.

Tentativas de correcao podem gerar eventos duplicados e efeitos colaterais inesperados.

So fazer dois writes

save DB
publish event

Nao garante consistencia.

2PC

Tem alta complexidade e baixa adocao em microsservicos modernos.

Persiste dados e evento no mesmo banco, na mesma transacao. Um processo separado le a tabela outbox e publica no broker.

Vantagens: atomicidade local, eventos nao se perdem, desacoplamento.

Trade-offs: latencia maior e complexidade operacional.

Ferramentas como Debezium observam mudancas direto no banco.

Vantagens: transparente para a aplicacao.

Desvantagens: infraestrutura mais complexa.

O proprio servico publica e consome os eventos, derivando o estado a partir deles.

Eventos se tornam a fonte de verdade:

append event -> event store -> projecoes derivadas

Estrategia	Consistencia	Complexidade	Controle
Dual-write ingenuo	Nenhuma	Baixa	Baixo
2PC	Forte	Muito alta	Alto
Outbox	Eventual	Media	Alto
CDC	Eventual	Alta	Medio
Event sourcing	Forte	Muito alta	Muito alto

O problema nao e escrever duas vezes. E tentar garantir consistencia sem um mecanismo confiavel.