Change Data Capture (CDC)

A técnica lê o log que o banco já usa para recuperação e replicação. PostgreSQL oferece logical decoding sobre WAL; MySQL registra mudanças em binary log; SQL Server CDC usa o transaction log e processos para materializar mudanças. Um conector interpreta insert, update e delete e produz eventos com posição, tabela, chave e valores. A vantagem é baixo impacto comparado a consultar todas as linhas e capacidade de capturar deletes. O leitor precisa manter checkpoint, como LSN, binlog filename/position ou GTID. Se o log é removido antes de o consumidor avançar, ocorre lacuna e pode ser necessário novo snapshot. A retenção do banco precisa superar indisponibilidade planejada. Acesso ao log exige privilégios e configuração. O formato interno pode mudar; usar APIs e plugins suportados.

SQL Server CDC cria tabelas de mudança associadas às tabelas capturadas e funções para consultar por intervalo de LSN. Inserts e deletes aparecem como linhas; updates podem registrar valores antes e depois conforme operação. Um job de captura lê o log e popula. Um job de cleanup aplica retenção. O consumidor consulta `fn_cdc_get_all_changes_*` ou funções equivalentes. Isso desacopla o leitor do log bruto, mas adiciona armazenamento e latência. A ativação é por banco e tabela, requer chave ou configuração para algumas capacidades. Alterações de schema precisam de gestão. Se a retenção expira antes da leitura, os LSNs deixam de estar disponíveis. O pipeline monitora início e fim da janela.

Triggers de INSERT, UPDATE e DELETE gravam numa tabela outbox ou de mudanças. É portável a bancos sem acesso a log e permite payload de domínio. A escrita ocorre na mesma transação, oferecendo atomicidade. O custo é aumentar latência e carga de cada operação. Triggers complexas são difíceis de depurar e podem bloquear. Recursão, ordem e bulk operations precisam de teste. A tabela cresce e requer limpeza. Um trigger pode registrar apenas chave e tipo; um worker lê detalhes. Para integração de casa inteligente, uma aplicação pode gravar evento de automação e alteração de estado numa outbox, depois publicar em MQTT. Isso é mais próximo do Transactional Outbox que CDC genérica, mas usa o mesmo princípio de capturar mudança confiavelmente.

Quando não há log ou trigger, o integrador consulta `WHERE updated_at > last_seen` em intervalos. É simples, mas possui limitações. Precisa de timestamp confiável, índice e desempate por ID. Atualizações com o mesmo timestamp e transações tardias podem ser perdidas. Deletes não aparecem sem tombstone ou coluna `deleted_at`. Relógio do servidor deve ser usado, não do cliente. Uma janela sobreposta, como reler os últimos 5 min e deduplicar, reduz lacunas. O cursor usa `(updated_at,id)`. Esse método é útil para APIs SaaS que expõem `modified_since`, mas não é equivalente a log CDC em consistência. A frequência de polling define latência e custo. Rate limits precisam ser respeitados.