CDC ou webhook para agentes de IA: como escolher

Um registro alterado pode exigir trabalhos muito diferentes

Uma oportunidade muda de etapa no CRM. O agente precisa preparar uma revisão comercial. Em outro processo, uma tabela de produtos recebe alterações e a empresa precisa atualizar o índice consultado pelo agente.

Os dois casos envolvem dados novos, mas pedem informações diferentes. O primeiro depende do significado da transição comercial. O segundo pode precisar apenas do estado atualizado dos produtos. Escolher a integração pela menor latência, sem separar essas necessidades, costuma aumentar o trabalho de recuperação e interpretação.

Change data capture, ou CDC, identifica alterações em uma fonte de dados. Em implementações baseadas no log transacional, acompanha mudanças confirmadas no banco. Webhooks entregam notificações emitidas pela aplicação. Consultas periódicas buscam informação em intervalos definidos e podem usar listagens completas, filtros ou um mecanismo incremental documentado.

Este guia ajuda a escolher o canal de mudanças. O procedimento para manter uma projeção entre rodadas está no artigo sobre sincronização incremental para agentes de IA. A implementação do recebimento de notificações está no guia de webhooks.

Primeiro, defina o que precisa ser preservado

Antes de avaliar conectores, escreva qual informação o consumidor precisa recuperar depois de uma interrupção:

O estado atual de cada objeto é suficiente?
Cada transição intermediária precisa ser processada?
A exclusão deve chegar aos índices e caches?
A tarefa depende de um evento de negócio confirmado pela aplicação?
Qual atraso ainda permite agir?
Qual é a maior interrupção que a operação precisa suportar?

Um catálogo de produtos pode tolerar consolidação de várias alterações em uma leitura atual. Uma rotina que acompanha obrigações geradas por transições pode perder trabalho se receber somente o último estado.

Se o agente precisar decidir com informação atual, também será necessário consultar a fonte da verdade antes da consequência. A entrega de um evento antigo não prova que a condição continua válida.

Quando CDC é uma opção pertinente

CDC faz sentido quando a empresa controla a fonte de dados, o banco oferece um mecanismo adequado e há equipe responsável por operá-lo. Pode alimentar réplicas, produtos analíticos, índices e integrações a partir de alterações nas tabelas.

A documentação do SQL Server oferece uma distinção concreta. Seu CDC captura informação histórica das mudanças, incluindo dados alterados, por um processo assíncrono que lê o log transacional. O recurso de change tracking registra quais linhas mudaram; os valores atuais são consultados nas tabelas de origem. São recursos diferentes e atendem necessidades diferentes.

Essa descrição vale para os recursos documentados do SQL Server. Outros bancos e conectores possuem contratos próprios. Confira edição, serviço, permissões, tabelas suportadas, operações capturadas, retenção e limitações de tipos antes de adotar o mecanismo.

CDC acrescenta responsabilidades operacionais:

acompanhar atraso da captura e do consumo;
proteger o acesso aos dados capturados;
coordenar carga inicial e início da captura;
preservar a posição de consumo;
tratar evolução de schema;
recuperar consumidores antes de a retenção eliminar mudanças necessárias.

A origem pode continuar saudável enquanto o consumidor perde a janela recuperável. O monitoramento precisa olhar essa distância e o tempo disponível para corrigir, além do estado do processo de captura.

Mudança de tabela não define intenção de negócio

Uma operação comercial pode alterar várias tabelas. Uma importação administrativa também pode produzir atualizações semelhantes. O CDC registra o que seu contrato oferece sobre o armazenamento; o significado operacional exige contexto adicional.

Evite transformar qualquer mudança em status numa ordem para o agente enviar uma mensagem. Defina o evento, as condições e a autoridade que permitem produzir aquela consequência.

Quando a aplicação controla a transação, o padrão outbox permite registrar o estado de negócio e o evento correspondente na mesma transação local. Um relay pode usar consulta periódica ou captura de mudanças para publicar a outbox. Nesse desenho, CDC transporta um evento que a aplicação já definiu, em vez de obrigar o consumidor a deduzir intenção a partir de tabelas internas.

Esse cuidado também reduz o acoplamento ao schema físico. Uma reorganização interna do banco não deveria mudar silenciosamente o que o consumidor entende por pedido aprovado.

Quando preferir webhook

Webhooks são uma opção natural quando o sistema de origem é um SaaS e expõe eventos de aplicação, mas não oferece acesso autorizado ao banco. Também podem ser úteis quando o evento precisa despertar um processo rapidamente.

A documentação do GitHub descreve a diferença entre receber uma entrega quando um evento ocorre e consultar repetidamente a API. Esse mecanismo evita consultas sem novidade, mas o contrato de cada fornecedor continua determinando o que pode ser recuperado.

Antes de escolher, confira quais eventos existem, quais campos acompanham a entrega, como autenticá-la e o que acontece em caso de falha. Algumas integrações oferecem histórico e reentrega; outras exigem recuperação por outro caminho.

A arquitetura precisa saber responder: se o receptor ficar indisponível, como descobrir quais objetos exigem trabalho depois? “O webhook voltará” só serve como plano quando a política de tentativas, sua duração e o mecanismo de recuperação foram verificados.

Quando consultas periódicas bastam

Consultas periódicas podem ser a melhor escolha para uma necessidade pouco urgente, um conjunto pequeno ou uma fonte que oferece um feed incremental confiável. Ter um horário de execução também facilita atribuir um dono e conferir o fechamento da rodada.

O risco está em supor que qualquer filtro por updated_at equivale a captura completa. Exclusões podem não aparecer. Alterações com o mesmo horário podem atravessar o corte. Um registro pode sofrer várias transições entre duas consultas.

Procure uma API de mudanças documentada quando precisar de continuidade. Ela pode entregar tokens, remoções e regras de retomada próprias. Consultar esse feed em intervalos continua sendo polling; o contrato incremental melhora a cobertura sem transformar a consulta em webhook ou CDC de banco.

Quando só existe listagem completa, dimensione leitura, comparação e tratamento de ausências. Um objeto que não veio numa resposta parcial não pode ser marcado como excluído antes da conferência de cobertura.

Escolha por impedimentos antes de comparar conveniência

Use esta sequência na decisão técnica:

Acesso permitido: descarte CDC se a empresa não controla nem possui autorização para capturar a fonte. Não contorne a fronteira de um SaaS para acessar seu armazenamento.
Informação exigida: descarte mecanismos que entreguem somente estado atual quando o processo precisa de transições intermediárias, salvo se outra fonte cobrir essa necessidade.
Recuperação: exija um caminho demonstrável para a interrupção prevista. A janela de retenção precisa comportar detecção, correção e recuperação.
Capacidade de operação: identifique quem mantém captura, assinatura, fila, checkpoint, permissões e mudanças de schema.
Prazo e carga: só então compare atraso, volume de consultas, infraestrutura e custo.

Registre a escolha por objeto. A empresa pode usar webhook para pedidos, consulta incremental para documentos e CDC para uma base que controla. Uniformizar tudo em um único canal pode eliminar garantias úteis.

Exemplo de decisão, com dados fictícios

Considere três demandas sintéticas:

D1: CRM externo, sem acesso ao banco; evento de oportunidade disponível;
    objetivo: despertar uma revisão e reler a oportunidade antes de agir.
D2: banco controlado pela empresa; precisa preservar alterações intermediárias;
    objetivo: alimentar consumidor com mudanças de tabelas selecionadas.
D3: biblioteca de documentos; API de mudanças com token e remoções;
    objetivo: manter índice atualizado, sem histórico integral de transições.

Para D1, avalie webhook com recuperação por API ou histórico, conforme suporte real do CRM. Para D2, CDC é um candidato, sujeito a habilitação, retenção, carga inicial e operação. Para D3, a consulta periódica ao feed incremental atende ao objeto proposto sem exigir acesso ao banco.

Essas são hipóteses de arquitetura, não testes de produtos. A decisão só fecha depois de demonstrar perda de conexão, exclusão, reentrega, interrupção além da retenção e mudança de schema na tecnologia escolhida.

O artefato de saída é um contrato de captura

Antes da implementação, registre em uma ficha:

Objeto e finalidade:
Informação necessária: estado atual | transições | evento de negócio
Canal principal:
Fonte e acesso autorizado:
Garantia documentada e limitações:
Carga inicial e posição de início:
Retenção recuperável:
Caminho de recuperação:
Prazo tolerado pelo processo:
Tratamento de exclusões:
Dono operacional e mantenedor técnico:
Testes de aceite e evidências:

Associe essa ficha ao contrato de dados. Ela deixa explícito o que a integração consegue entregar e evita que o agente receba uma promessa de cobertura maior que a fonte oferece.

Fontes oficiais verificadas em 20 de outubro de 2026

Microsoft Learn: rastrear alterações de dados no SQL Server, para a diferença entre CDC e change tracking, informação histórica e leitura dos valores atuais.
GitHub Docs: sobre webhooks, para o mecanismo de assinatura de eventos, entregas e comparação com polling da API.

A sequência de escolha e a ficha de captura são recomendações da Júpiter. As fontes descrevem mecanismos específicos; não garantem as mesmas condições em qualquer banco ou SaaS. Valide o contrato do fornecedor e o processo de recuperação antes de liberar ações do agente.