Case study
1 min de leituraPostgres → MongoDB CDC
Pipeline idempotente de change data capture
Migrar de Postgres para MongoDB sem janela de manutenção, sem perder evento, sem duplicar evento, mesmo com o sink caindo no meio da carga.
Pipeline de change data capture
Decisões
Debezium como leitor do WAL
Leitor logical-replication oficialmente suportado, com snapshot inicial controlado e streaming subsequente via plugin pgoutput. Posição do leitor é o LSN, garantia de ordem por partição da tabela.
Transformer em Go entre Kafka e o sink
Aplica o mapeamento de schema relacional para documento Mongo. Go pelo perfil de latência: GC previsível, goroutines leves para fan-out por collection, sem JIT warmup.
Idempotência por chave + LSN
O sink escreve com upsert controlado por (chave_natural, lsn). Se o evento já chegou (LSN <= último visto), no-op. Reprocessar a partir de qualquer ponto do WAL é seguro por construção.
Chaos testing como rotina
Bateria que mata o sink no meio da carga, parte o link Kafka, atrasa o ack. O critério de aceite é: zero perda, zero duplicação, lag converge para zero quando o pipeline volta.
“Idempotência não é uma propriedade que se demonstra: é uma postura defensiva que se incorpora no design desde o primeiro upsert.”
Tradeoffs
Latência vs durabilidade no Kafka
acks=all e replicação 3 dão durabilidade ao custo de latência. Para CDC operacional o trade vale; para eventos best-effort não valeria.
Schema do Mongo derivado, não desenhado
O documento Mongo é função do schema Postgres mais regras de denormalização. É mais barato de migrar, mais difícil de evoluir o modelo Mongo independentemente. Decisão consciente: privilegiar reversibilidade sobre elegância do modelo destino.
Estado atual
O pipeline ainda evolui. O próximo passo é instrumentar o lag por collection num Grafana exclusivo e definir SLO de janela de convergência por classe de tabela.