Change Data Capture: o que é CDC e como funciona
Entenda como o CDC captura alterações no banco de dados, sincroniza sistemas e quais cuidados aplicar em snapshots, reentregas e consumidores.
Quando um pedido muda de status, vários sistemas podem precisar saber disso: estoque, entrega, atendimento, análise de dados e notificações.
Consultar repetidamente a tabela inteira funciona em cenários pequenos, mas gera atraso, carga e casos difíceis de tratar, como exclusões.
Change Data Capture, ou CDC, é uma abordagem para identificar inserções, atualizações e exclusões realizadas em uma fonte de dados e disponibilizá-las para outros processos.
Em implementações baseadas no log transacional, o capturador acompanha mudanças já confirmadas pelo banco e as transforma em um fluxo de eventos.
Isso permite sincronizar destinos com baixa latência sem executar uma consulta completa a cada ciclo.
CDC não elimina os desafios de consistência. É preciso planejar snapshot inicial, posição de leitura, reentregas, ordenação, mudanças de esquema, exclusões, segurança e recuperação.
Este guia mostra como essas peças se conectam e quando a técnica realmente vale a pena.
O que é Change Data Capture?
Change Data Capture é o processo de detectar alterações em dados e entregá-las a sistemas interessados.
A mudança pode ser a criação de uma linha, a atualização de colunas ou a exclusão de um registro.
Em vez de perguntar constantemente “o que mudou desde a última consulta?”, um mecanismo CDC acompanha uma fonte de alterações.
Nos bancos relacionais, essa fonte costuma ser o log usado pelo próprio banco para durabilidade e recuperação.
No PostgreSQL, a decodificação lógica transforma registros do WAL em uma forma compreensível para consumidores. No MySQL, o binary log registra eventos usados na replicação e pode representar mudanças por linha, instrução ou formato misto.
Entender transações, chaves e integridade ajuda a evitar decisões erradas. O artigo sobre bancos de dados relacionais apresenta essa base.
Para que serve CDC?
- atualizar um índice de busca quando os dados operacionais mudam;
- alimentar data warehouse, lakehouse ou pipelines analíticos;
- manter um cache ou uma visão de leitura sincronizada;
- propagar mudanças entre serviços sem consultar repetidamente a origem;
- atualizar embeddings quando documentos são alterados ou removidos;
- modernizar sistemas legados de forma gradual;
- integrar fontes diferentes com menor atraso.
Em uma aplicação de busca semântica, por exemplo, o CDC pode avisar que um documento mudou.
O pipeline refaz os trechos e atualiza o banco de dados vetorial, evitando que resultados antigos continuem aparecendo.
Como Change Data Capture funciona
Uma arquitetura comum possui quatro partes: banco de origem, conector CDC, meio de transporte e consumidores. O conector lê mudanças confirmadas, converte cada uma em uma representação estável e registra até onde avançou.
O transporte pode ser um broker, fila, stream ou mecanismo próprio. Os consumidores transformam ou aplicam as mudanças em destinos como outro banco, índice de busca e armazenamento analítico.
Snapshot inicial
O log normalmente contém mudanças recentes, não uma cópia completa de tudo que já existe.
Por isso, um novo pipeline costuma começar com um snapshot consistente das tabelas e depois continuar pelo log a partir de uma posição coordenada.
Se snapshot e streaming não forem sincronizados, mudanças feitas durante a cópia podem ser perdidas ou aplicadas fora de ordem.
A documentação do conector PostgreSQL do Debezium descreve modos de snapshot e retomada por LSN.
Leitura contínua e posição no log
Depois do snapshot, o conector acompanha o log e guarda um offset. No PostgreSQL, essa posição pode ser um LSN; em outras fontes, pode ser outro identificador de arquivo, transação ou sequência.
Após uma reinicialização, o processo usa a posição persistida para retomar.
Como a confirmação do offset e a entrega do evento podem ocorrer em momentos diferentes, algumas alterações podem reaparecer.
Esse comportamento é um motivo para projetar consumidores idempotentes.
O que existe em um evento CDC
O formato varia, mas um evento pode conter a operação, chave primária, estado anterior, estado posterior, tabela de origem, horário, posição no log e identificadores de transação.
{
"operacao": "atualizacao",
"chave": { "pedido_id": 8421 },
"antes": { "status": "pago" },
"depois": { "status": "separacao" },
"origem": { "tabela": "pedidos", "posicao": "..." }
}Esse exemplo é didático. O formato real depende do conector e da configuração do banco.
Em algumas tabelas, o estado anterior não estará completo; em exclusões, pode haver apenas a chave necessária para remover o registro no destino.
Principais formas de capturar mudanças
Consultas periódicas
O consumidor consulta linhas com updated_at posterior à última execução.
É simples para baixo volume, mas exige cuidado com empates de horário, relógios, transações demoradas e paginação.
Exclusões não aparecem sem uma marca lógica ou tabela auxiliar.
Triggers e tabelas auxiliares
Triggers gravam as mudanças em uma tabela de auditoria ou outbox.
A abordagem oferece controle sobre o conteúdo, mas acrescenta trabalho à transação da aplicação e precisa acompanhar alterações no esquema.
CDC baseado em log
O conector lê a trilha transacional mantida pelo banco. Isso reduz a necessidade de varrer tabelas e permite capturar exclusões e metadados de ordenação.
Em troca, exige permissões específicas, retenção de logs, conhecimento do motor e uma estratégia para mudanças de esquema.
| Abordagem | Vantagem | Cuidado principal |
|---|---|---|
| Consulta periódica | Implementação inicial simples | Atraso, carga e exclusões |
| Trigger | Controle do evento gravado | Impacto na escrita e manutenção |
| Baseada em log | Baixa interferência e boa cobertura | Operação, permissões e retenção |
Exemplo prático em um e-commerce
Considere a tabela pedidos. Quando o serviço de pagamento confirma uma compra, a mesma transação atualiza o status.
O conector CDC lê a mudança confirmada e publica um evento.
- O consumidor de estoque reserva os itens.
- O serviço de entrega prepara a expedição.
- O índice de atendimento atualiza a visão do pedido.
- O pipeline analítico registra a conversão.
Em uma arquitetura de microsserviços, cada consumidor mantém sua responsabilidade.
Mesmo assim, o evento de linha não explica necessariamente a intenção “pagamento aprovado”; ele apenas descreve que um valor mudou.
CDC, replicação e event sourcing são iguais?
Não. Replicação busca manter outra cópia do banco para disponibilidade ou leitura. CDC expõe alterações para integrações e múltiplos consumidores. As duas técnicas podem usar o mesmo log, mas têm objetivos diferentes.
No event sourcing, eventos de domínio são a fonte de verdade e o estado é derivado deles.
No CDC tradicional, a tabela continua sendo a fonte e os eventos são derivados das mudanças persistidas. Um evento “linha atualizada” também possui menos significado de negócio que “pedido aprovado”.
Entrega, duplicidade e idempotência
Muitos pipelines priorizam não perder alterações e aceitam que um evento seja entregue novamente após falha.
A documentação do Debezium sobre garantias de entrega informa que o padrão é at least once: mudanças não são omitidas, mas um registro pode aparecer mais de uma vez.
Um consumidor idempotente chega ao mesmo estado mesmo processando a mesma mudança duas vezes. Para sincronizar uma tabela, isso pode significar fazer upsert pela chave e guardar a última versão ou posição aplicada.
Operações como “incrementar saldo” ou “enviar e-mail” não são naturalmente idempotentes.
Elas precisam de uma chave de deduplicação, registro de processamento ou desenho transacional que impeça a repetição do efeito.
Ordenação e limites de transação
O log oferece uma ordem na origem, mas o transporte pode particionar eventos e os consumidores podem processá-los em paralelo.
Preserve a ordem necessária por entidade usando uma chave estável, como pedido_id.
Não presuma uma ordem global entre tabelas e partições. Se duas mudanças precisam ser interpretadas juntas, mantenha metadados da transação ou modele um evento de domínio que represente a operação completa.
Exclusões, tombstones e dados antigos
CDC baseado em log pode capturar exclusões, mas o evento talvez contenha somente a chave. O consumidor deve interpretar esse sinal e remover, ocultar ou marcar o item no destino.
Alguns streams usam um registro adicional chamado tombstone para permitir limpeza em tópicos compactados.
Defina claramente a diferença entre exclusão física, exclusão lógica e expiração, especialmente quando dados pessoais precisam desaparecer de todas as cópias.
Mudanças de esquema
Adicionar, renomear ou remover uma coluna altera o contrato dos eventos.
Consumidores rígidos podem falhar mesmo quando o banco aceita a migração.
- prefira mudanças compatíveis e em etapas;
- adicione campos antes de torná-los obrigatórios;
- mantenha consumidores capazes de ignorar campos desconhecidos;
- versione contratos quando a semântica mudar;
- teste migração, captura e destino no mesmo cenário.
ORMs simplificam a persistência da aplicação, mas não escondem esse contrato do pipeline. Vale conectar o planejamento com as práticas de mapeamento objeto-relacional e migrações.
CDC e transactional outbox
Publicar no banco e no broker em duas operações independentes cria o problema de dual write: uma pode confirmar e a outra falhar.
O transactional outbox grava o estado e um evento de negócio na mesma transação do banco.
Depois, um relay ou conector CDC publica a linha da outbox.
A orientação da AWS sobre transactional outbox mostra como a abordagem evita inconsistências entre o commit e a notificação.
A outbox oferece intenção de domínio, enquanto capturar diretamente qualquer tabela reduz alterações na aplicação, mas expõe detalhes do armazenamento.
Segurança e proteção de dados
Um pipeline CDC pode multiplicar dados sensíveis em tópicos, caches, logs e ambientes analíticos.
Capture apenas tabelas e colunas necessárias, aplique criptografia, controle de acesso e períodos de retenção compatíveis com a finalidade.
Credenciais do conector devem ter o menor privilégio possível. Segredos não devem aparecer na configuração versionada, e o acesso ao log não pode se transformar em acesso irrestrito a todo o banco.
As mesmas práticas de segurança desde o código precisam alcançar conectores e consumidores.
O que monitorar em produção
- Lag: diferença entre a mudança na origem e a aplicação no destino.
- Posição: último offset confirmado e idade do evento mais antigo.
- Retenção: volume de WAL, binlog ou tabelas CDC aguardando consumo.
- Taxa e erros: eventos por segundo, falhas de serialização e tentativas.
- Consumidores: filas de mensagens mortas, reprocessamentos e divergência no destino.
- Esquema: mudanças incompatíveis e campos inesperados.
No PostgreSQL, slots podem reter WAL quando o consumidor para de avançar. Um slot esquecido pode ocupar armazenamento indefinidamente.
Integre métricas do conector e do banco à estratégia de observabilidade com OpenTelemetry.
Quando não usar CDC
Uma tarefa diária com poucas linhas pode ser resolvida por um job incremental simples.
CDC adiciona conectores, retenção, contratos, monitoramento e recuperação. O ganho precisa justificar essa operação.
Também não use eventos de linha como API pública sem uma camada de contrato. O esquema interno pode mudar e expor campos que consumidores não deveriam conhecer.
Quando a intenção de negócio é essencial, outbox ou eventos produzidos pela aplicação tendem a ser mais claros.
Checklist de implementação
- Defina fonte, tabelas, colunas e consumidores.
- Escolha entre polling, trigger e leitura do log.
- Planeje snapshot e posição de transição para streaming.
- Defina chave, partição, ordenação e formato do evento.
- Torne cada consumidor idempotente.
- Teste inserção, atualização, exclusão e mudança de esquema.
- Simule parada após entrega e antes da confirmação do offset.
- Crie reprocessamento, reconciliação e fila de erros.
- Monitore lag, retenção, armazenamento e falhas.
- Restrinja dados, permissões e tempo de retenção.
Perguntas frequentes
CDC substitui uma fila ou um broker?
Não. CDC captura mudanças; o broker transporta, armazena e distribui eventos. Algumas plataformas combinam as funções, mas elas continuam conceitualmente diferentes.
Change Data Capture funciona em tempo real?
Normalmente funciona próximo do tempo real. A latência depende do banco, conector, transporte, volume, consumidores e destino; não há garantia de resposta instantânea.
CDC pode perder dados?
Pode, se estiver mal configurado ou se o log necessário expirar antes da leitura. Retenção, offsets, alertas e testes de recuperação são essenciais.
Por que eventos podem aparecer duplicados?
Uma falha pode ocorrer depois da entrega e antes da confirmação da posição. Ao retomar, o conector reenvia a mudança para evitar perdê-la.
CDC captura exclusões?
CDC baseado em log geralmente captura exclusões. A quantidade de dados anteriores disponível depende do banco, da chave e da configuração.
É preciso usar Kafka para ter CDC?
Não. Kafka é uma opção comum para transportar streams, mas CDC também pode alimentar filas, serviços de streaming, runtimes embutidos ou destinos diretos.
Conclusão
Change Data Capture conecta o histórico transacional do banco a sistemas que precisam reagir às mudanças.
Quando bem aplicado, reduz consultas repetitivas, diminui o atraso de sincronização e cria uma base consistente para busca, análise e integração.
O valor vem acompanhado de responsabilidades: coordenar snapshot e streaming, preservar posições, aceitar reentregas, construir consumidores idempotentes, tratar esquemas e monitorar a retenção.
Comece por um fluxo pequeno, teste falhas deliberadamente e só amplie depois que recuperação e reconciliação estiverem comprovadas.