CDC no PostgreSQL começa no WAL

Imagine um sistema responsável por gerenciar escolas e alunos de uma rede de ensino. No banco de dados principal, uma nova escola é cadastrada. Em seguida, centenas de alunos são vinculados a ela.

Essas informações precisam ser utilizadas por outros sistemas: um sistema de relatórios, um ambiente de BI, um serviço de notificações ou até mesmo uma aplicação responsável por alimentar uma base de dados específica para consultas.

Uma abordagem simples seria fazer esses outros sistemas consultarem periodicamente o banco principal para descobrir o que mudou. Mas logo surgem algumas perguntas:

• Como saber quais registros foram alterados?
• Como evitar consultar milhares ou milhões de registros desnecessariamente?
• Como garantir que uma alteração no cadastro de um aluno seja propagada para os outros sistemas?

É nesse tipo de cenário que entra o Change Data Capture (CDC).

Em vez de ficar perguntando ao banco a todo momento se alguma coisa mudou, podemos capturar as alterações à medida que elas acontecem e transformá-las em eventos que podem ser consumidos por outros sistemas.

Quando comecei a estudar esse assunto, pensei logo em CDC, Debezium e Kafka Connect. Mas descobri que, no PostgreSQL, tudo começa muito antes disso.

Existe o WAL (Write-Ahead Log), um mecanismo criado para garantir a recuperação e a consistência do banco de dados. Sempre que ocorre um INSERT, UPDATE ou DELETE, essa alteração é registrada primeiro no WAL.

O detalhe interessante é que ferramentas de CDC, como o Debezium, não ficam monitorando tabelas. Elas consomem as alterações produzidas a partir do WAL por meio da replicação lógica e as transformam em eventos para outras aplicações.

Em outras palavras:

WAL -> Replicação Lógica -> Debezium/Kafka Connect -> Outros sistemas

Compreender essa sequência ajuda a entender que o CDC não nasce no Kafka. Ele começa dentro do próprio PostgreSQL. É um daqueles detalhes de infraestrutura que, quando você entende, faz várias peças se encaixarem.