Apache Kafka e CDC: Streaming de Eventos em Tempo Real e Ingestão Transacional Contínua

Em arquiteturas empresariais integradas, a sincronização de dados entre múltiplos sistemas frequentemente dependia de rotinas noturnas em lote (batch processing). A cada 24 horas, scripts lentos varriam tabelas inteiras de bancos de dados relacionais em busca de registros com carimbos atualizados, transferindo informações com atraso de um dia inteiro para os repositórios corporativos.

Esse modelo de sincronização periódica colapsou diante das exigências contemporâneas de resposta imediata: sistemas antifraude precisam detectar comportamentos suspeitos em milissegundos, sistemas logísticos exigem rastreamento de entregas ao vivo e plataformas de comércio necessitam de saldo de estoque atualizado instantaneamente em todos os canais.

A união do Apache Kafka como plataforma distribuída de streaming com o padrão Change Data Capture (CDC) viabilizou a transição definitiva para a ingestão contínua de dados em tempo real, sem impor lentidão aos bancos de dados de produção.

A Arquitetura do Apache Kafka: O Log de Commit Distribuído

Diferente de corretores de mensageria tradicionais projetados para enfileirar mensagens temporárias em memória, o Apache Kafka funciona estruturalmente como um log de transações ordenado, append-only e persistente em disco:

graph LR
    subgraph T["TÓPICO: pedidos-realizados"]
        direction TB
        subgraph P0["Partição 0"]
            direction LR
            P0_O0["Offset 0"] --> P0_O1["Offset 1"] --> P0_O2["Offset 2"] --> P0_O3["Offset 3"]
        end
        subgraph P1["Partição 1"]
            direction LR
            P1_O0["Offset 0"] --> P1_O1["Offset 1"] --> P1_O2["Offset 2"]
        end
        subgraph P2["Partição 2"]
            direction LR
            P2_O0["Offset 0"] --> P2_O1["Offset 1"]
        end
    end

    Produtor["<b>Produtor</b><br/>(Grava no final)"] --> T
    T --> Consumidor["<b>Consumidor</b><br/>(Controla seu Offset)"]

    classDef cluster fill:#0a0f1d,stroke:#38bdf8,stroke-width:2px,color:#f8fafc;
    classDef part fill:#131d30,stroke:#64748b,stroke-width:1px,color:#f8fafc;
    classDef offset fill:#1e293b,stroke:#38bdf8,stroke-width:1px,color:#f8fafc;
    classDef actor fill:#0f172a,stroke:#4ade80,stroke-width:2px,color:#f8fafc;

    class T cluster;
    class P0,P1,P2 part;
    class P0_O0,P0_O1,P0_O2,P0_O3,P1_O0,P1_O1,P1_O2,P2_O0,P2_O1 offset;
    class Produtor,Consumidor actor;

1. Tópicos e Particionamento

Os eventos são publicados em categorias lógicas chamadas Tópicos (Topics). Para permitir escala horizontal massiva, cada tópico é fatiado em múltiplas Partições distribuídas entre diferentes servidores do cluster (Brokers). O Kafka garante a ordenação estrita das mensagens dentro de uma mesma partição; logo, mensagens que compartilham a mesma chave de partição (como o ID_Cliente) são sempre gravadas na mesma partição e processadas na ordem cronológica exata em que aconteceram.

2. O Conceito de Offset e Retenção em Disco

Cada evento gravado em uma partição recebe um identificador sequencial imutável chamado Offset. As mensagens não são apagadas após a leitura por um consumidor: elas permanecem salvas em disco pelo período de retenção configurado (dias, semanas ou indefinidamente).

Cada aplicação consumidora monitora de forma independente seu próprio cursor de leitura (offset commit). Isso significa que múltiplos sistemas (o faturamento, a expedição e o Data Warehouse) podem ler o mesmo tópico simultaneamente, cada qual em sua própria velocidade, e até rebobinar seus cursores para reprocessar eventos históricos em caso de auditoria ou correção de bugs.

Comparativo: Apache Kafka versus RabbitMQ

A diferenciação entre as duas tecnologias de mensageria mais populares resume-se à filosofia de armazenamento:

Critério	Apache Kafka	RabbitMQ
Paradigma Central	Log de streaming distribuído persistente em disco.	Fila de mensagens em memória com roteamento inteligente.
Ciclo de Vida do Dado	Persistente; a leitura não destrói a mensagem no cluster.	Efêmero; a mensagem é deletada após confirmação (ACK).
Controle de Leitura	Descentralizado; o consumidor controla seu próprio Offset.	Centralizado; o broker orquestra a entrega das filas.
Capacidade de Vazão	Milhões de eventos por segundo com latência de milissegundos.	Dezenas de milhares de mensagens por segundo.
Cenário Recomendado	Ingestão contínua de dados, telemetria, CDC e Big Data.	Filas de processamento assíncrono e tarefas demoradas.

Change Data Capture (CDC): Ingestão sem Sobrecarga

O padrão Change Data Capture (CDC) atua como a ponte ideal entre bancos relacionais transacionais (OLTP) e o ecossistema de streaming do Kafka.

Historicamente, ferramentas de integração tentavam ler mudanças executando consultas periódicas com WHERE data_modificacao > :ultima_execucao. Essa abordagem de varredura (polling) causa problemas graves: exige índices pesados em colunas de data, consome recursos de CPU do banco de produção e é incapaz de capturar comandos de exclusão física (DELETE), pois o registro simplesmente desaparece sem deixar rastros.

graph TD
    DB["<b>Banco Transacional</b><br/>(PostgreSQL / MySQL)"] -->|Gravação Transacional ACID| WAL["<b>Log de Transações</b><br/>(WAL / Binlog)"]
    WAL -->|Leitura passiva sem travar tabelas| CDC["<b>Debezium (Conector CDC)</b>"]
    CDC -->|Emite eventos de mutação em tempo real| KAFKA["<b>Apache Kafka (Cluster)</b>"]

    KAFKA --> ES["<b>Elasticsearch</b><br/>(Atualiza Índice de Busca)"]
    KAFKA --> MS["<b>Microsserviço Consumidor</b><br/>(Reage a Regras de Negócio)"]
    KAFKA --> DW["<b>Data Warehouse / Data Lake</b><br/>(Alimenta Camada Analítica)"]

    classDef storage fill:#0f172a,stroke:#38bdf8,stroke-width:2px,color:#f8fafc;
    classDef broker fill:#1e293b,stroke:#4ade80,stroke-width:2px,color:#f8fafc;
    classDef dest fill:#131d30,stroke:#64748b,stroke-width:1px,color:#f8fafc;

    class DB,WAL storage;
    class CDC,KAFKA broker;
    class ES,MS,DW dest;

O CDC moderno opera através da leitura passiva dos arquivos de log de transação nativos do banco de dados:

• No PostgreSQL, consome diretamente o Write-Ahead Logging (WAL).
• No MySQL, lê o Binary Log (Binlog).
• No SQL Server, monitora os registros de log de transações.

Ferramentas especializadas como o Debezium (rodando sobre o Kafka Connect) interceptam cada inserção, alteração e exclusão diretamente no nível de bytes do log de transações, antes mesmo que os blocos sejam liberados. O conector converte essa mutação em um evento JSON ou Avro estruturado contendo o estado anterior do registro (before), o estado posterior (after) e metadados operacionais, publicando-o imediatamente em um tópico Kafka.

Vantagens Práticas para a Arquitetura Corporativa

A combinação de Apache Kafka e CDC entrega benefícios imediatos para a modernização de sistemas:

1. Zero Impacto no Banco de Produção: Como o Debezium lê arquivos de log sequenciais em disco e não executa comandos SQL nas tabelas de dados, a operação dos clientes da aplicação continua com desempenho pleno.
2. Sincronização em Tempo Real de Múltiplos Destinos: Um único evento de alteração de cliente pode ser consumido simultaneamente para atualizar o índice de busca no Elasticsearch, invalidar caches no Redis e alimentar o Data Warehouse em nuvem.
3. Consistência Eventual Segura: Em processos de migração de sistemas legados, o CDC atua como o mecanismo de espelhamento que mantém o novo banco de dados sincronizado com o banco antigo até a virada de chave definitiva.