Change Data Capture (CDC) é a técnica que mantém múltiplos sistemas com o mesmo dado, propagando cada mudança no momento em que ela acontece na origem. Em vez de perguntar periodicamente “o que mudou desde a última vez?”, o CDC lê diretamente o registro interno de mudanças do banco de dados e replica cada alteração — criação, atualização ou exclusão — para todo destino que precisa saber.
A analogia mais próxima é um sistema de notas fiscais eletrônicas bem desenhado: toda vez que uma venda acontece, a nota é emitida automaticamente e uma cópia chega a cada órgão que precisa dela — não é preciso que alguém, uma vez por mês, reúna todas as vendas do período e as declare manualmente. O evento gera a propagação; ninguém precisa ficar perguntando.
O problema que o CDC resolve
A quantidade de dado gerado por operações de marketing cresce continuamente — a maior parte do volume de dados do mundo foi criada nos últimos dois anos, segundo estimativas do setor. O desafio não é armazenar esse volume; é aproveitá-lo em tempo real, enquanto bancos de produção, data lakes, data warehouses e caches ficam constantemente dessincronizados entre si.
Esse é exatamente o cenário de martech: um lead muda de status no CRM, mas o CDP ainda mostra o status antigo; um pedido é cancelado no e-commerce, mas o data warehouse de BI continua contando como venda; um contato atualiza o e-mail, mas a ferramenta de automação dispara para o endereço desatualizado. Cada um desses é um sintoma de sistemas que deveriam refletir o mesmo dado, mas não têm um mecanismo confiável de sincronização.
A alternativa amadora e por que ela falha
A resposta mais comum, na ausência de CDC, é a exportação agendada: um job roda todo dia às 3h da manhã, extrai tudo (ou tudo desde a última execução) do sistema de origem e importa no destino. Funciona por um tempo, mas carrega três limitações estruturais:
- Atraso garantido. Entre a mudança real e a próxima execução do job, o destino está desatualizado — na melhor das hipóteses, por horas.
- Delеções somem. Uma exportação que lista “o que existe agora” não informa “o que foi apagado desde a última vez”. Registros excluídos na origem continuam vivos no destino indefinidamente, a menos que exista uma lógica extra e frágil para detectar isso.
- Carga desnecessária no banco de produção. Rodar uma consulta pesada todo dia contra o banco que sustenta a operação ao vivo compete por recursos com o próprio sistema que os clientes estão usando naquele momento.
Como o CDC funciona, em cinco passos
A elegância do CDC está em onde ele busca a informação: não consulta as tabelas de dado diretamente, mas lê o log de transação que o próprio banco já mantém internamente para garantia de integridade e recuperação de falhas.
- Uma mudança acontece no banco de origem — um insert, update ou delete, disparado por uma ação normal do sistema.
- A ferramenta de CDC lê o log de transação do banco, o mesmo registro interno que ele já usa para sua própria consistência — não é uma consulta extra às tabelas, é uma leitura de um log que já existia.
- A mudança é transformada para o formato esperado pelo destino — nomes de campo, tipos de dado, estrutura.
- A mudança é publicada numa fila de eventos e propagada para quem precisar dela: data warehouses, ferramentas de analytics e caches como Redis.
- O conector de destino (sink connector) atualiza o sistema-alvo em tempo real, aplicando a mesma mudança que aconteceu na origem.
A frase que resume o valor prático: quem opera o sistema só precisa se preocupar com o passo 1 — fazer a mudança normalmente, como sempre fez. Todos os passos seguintes são transparentes e automáticos.
Por que ler o log resolve o problema das delеções
A vantagem mais subestimada do CDC baseado em log é capturar tudo — inclusive exclusões — na ordem exata em que aconteceram, sem impor carga extra de consulta ao banco de produção. Isso acontece porque o log de transação já registra toda mudança, incluindo delеções, como parte do funcionamento normal do banco — o CDC apenas lê algo que já está sendo escrito de qualquer forma.
Uma exportação periódica nunca resolve isso de forma limpa: comparar “o que existe hoje” com “o que existia ontem” para inferir delеções é caro computacionalmente e frágil quando o volume cresce. O CDC não precisa inferir nada — a delеção já está registrada no log, com timestamp e identificação exata do registro afetado.
A stack de referência e um exemplo real
A combinação mais citada como referência de mercado é Debezium (projeto open-source lançado pela Red Hat em 2016) integrado ao Kafka Connect. Debezium é responsável por ler o log de transação de bancos como PostgreSQL, MySQL ou MongoDB e publicar cada mudança como um evento no Kafka; a partir daí, qualquer sistema inscrito nesse fluxo — data warehouse, cache, motor de busca — recebe a atualização.
O Reddit usa exatamente essa combinação para manter cache e réplicas de leitura coerentes com o banco principal, numa operação que atende cerca de um bilhão de usuários por mês. É um exemplo de escala real de como CDC deixa de ser um recurso avançado para virar infraestrutura básica quando o volume de mudanças simultâneas se torna alto o suficiente.
A resposta técnica correta para uma pergunta comum em martech
“Como mantemos CRM, CDP, e-commerce e data warehouse com o mesmo dado?” é uma das perguntas mais recorrentes em qualquer operação de martech com mais de duas ferramentas centrais. CDC é a resposta de engenharia para esse problema — não a única possível, mas a que resolve as três limitações da exportação agendada ao mesmo tempo: atraso, delеções perdidas e carga no banco de produção.
Isso não significa que toda operação precisa de CDC imediatamente. É uma decisão de arquitetura que se paga quando o custo do dado desatualizado — decisão de campanha baseada em segmento errado, e-mail enviado para contato já excluído, relatório de BI que não bate com o CRM — supera o custo de operação de manter o pipeline de CDC funcionando.
Onde CDC entra na conversa com o time de dados
Ao perceber divergência entre sistemas — o CRM diz uma coisa, o dashboard de BI diz outra —, a pergunta que revela se existe ou não um mecanismo real de sincronização é:
“O dado chega ao warehouse por CDC lendo o log do banco, ou por exportação agendada? E se um registro for excluído na origem, isso se reflete automaticamente aqui, ou fica órfão?”
Essa pergunta separa uma operação de dados madura de uma que está usando gambiarra de CSV disfarçada de “integração automatizada” — e explica, sem jargão técnico desnecessário, por que um dashboard pode estar sempre disponível e ainda assim sempre errado por alguns minutos ou horas.
O custo de operar CDC não é zero
Vale um contraponto honesto: CDC resolve um problema real, mas não é gratuito de operar. Ler o log de transação de um banco de produção exige acesso privilegiado a uma parte sensível da infraestrutura, e a ferramenta de CDC em si — Debezium ou equivalente — precisa ser mantida, monitorada e atualizada como qualquer outro componente crítico do pipeline de dado. Um pipeline de CDC mal monitorado pode falhar silenciosamente, e o sintoma de uma falha silenciosa em CDC é sutil: os sistemas de destino simplesmente param de receber atualização, sem nenhum erro óbvio no sistema de origem, que continua funcionando normalmente sem saber que ninguém mais está lendo seu log.
Isso reforça que CDC é uma decisão de investimento em infraestrutura de dado, não um recurso que se ativa e esquece. Operações que adotam CDC sem dedicar monitoramento específico a ele frequentemente descobrem meses depois que a sincronização parou de funcionar há semanas, e ninguém percebeu porque cada sistema individualmente parecia saudável.
O que CDC não resolve sozinho
Vale um alerta de escopo. CDC resolve a propagação da mudança — não resolve automaticamente:
- Divergência de schema entre origem e destino — se os sistemas usam nomes ou tipos de campo diferentes, ainda é preciso uma camada de transformação, geralmente parte do próprio pipeline de ETL.
- Conflito de escrita simultânea — se dois sistemas podem alterar o mesmo dado de forma independente, CDC propaga ambas as mudanças, mas não decide qual delas “vence”.
- Qualidade do dado na origem — CDC replica fielmente o que está na origem, incluindo erros de digitação, duplicatas e dado mal formatado. Sincronização rápida de dado ruim ainda é dado ruim, só que mais rápido.
CDC como alternativa ao webhook para sincronização de dado
Vale distinguir CDC de webhook, porque os dois resolvem “avisar outro sistema sobre uma mudança” de formas diferentes e com trade-offs próprios. Um webhook depende de o sistema de origem ter sido explicitamente programado para disparar uma notificação a cada tipo específico de evento — se o desenvolvedor não previu aquele gatilho, a mudança simplesmente não gera aviso nenhum. CDC não depende de nenhuma programação específica por evento: ele lê o log de transação do banco, que registra toda mudança de qualquer natureza, independentemente de alguém ter pensado em notificar sobre ela.
Isso torna CDC mais abrangente por padrão, mas também mais próximo da infraestrutura do banco — geralmente exige acesso e permissão em nível mais profundo do sistema de origem do que simplesmente configurar um webhook na interface de um SaaS. Na prática, muitas operações combinam os dois: webhook para eventos de negócio específicos e conhecidos (novo pedido, cancelamento), e CDC para a sincronização ampla e completa entre sistemas de dado que precisam estar sempre coerentes entre si.
Próximos passos para avaliar sua sincronização
A ação concreta: pergunte ao time de dados ou ao fornecedor de CDP/data warehouse como a sincronização entre CRM e os demais sistemas acontece hoje — CDC, exportação agendada, ou webhook pontual disparado por evento específico. A resposta determina o tamanho real do atraso entre “o dado mudou” e “todo sistema sabe disso”.
Se a resposta for exportação em CSV rodando de madrugada, isso não é necessariamente errado para o volume atual da operação — mas é o primeiro lugar a olhar quando o negócio crescer o suficiente para que um atraso de horas comece a custar decisão de campanha ou reclamação de cliente.
