Quando outra coisa precisa saber

Captura de dados de mudança é a prática de transformar as escritas no seu banco num fluxo de eventos que outros sistemas podem consumir. O nome descreve o mecanismo, e o problema que ele resolve é mais antigo que o nome.

O problema

Uma linha muda, e alguma coisa fora da aplicação precisa saber.

Um índice de busca precisa ser refeito. Um data warehouse precisa do número novo. Um cache em outro serviço agora está errado. Um e-mail precisa sair, uma trilha de auditoria precisa registrar a mudança, uma API parceira precisa ser avisada.

A resposta ingênua é fazer tudo isso na hora, na mesma requisição que fez a mudança. Isso amarra o seu caminho de escrita a cada consumidor, e o consumidor que estiver lento, ou fora do ar, vira problema seu.

Por que isso é mais difícil do que parece

O banco já sabe de toda mudança: o write-ahead log dele registra cada uma. A dificuldade é tirar esse conhecimento de lá de forma confiável, e "confiável" esconde três exigências que puxam umas contra as outras.

Nada pode se perder. Uma mudança que não gera evento é uma inconsistência permanente, e ninguém descobre até os dois sistemas serem comparados.

A ordem precisa ser mantida, pelo menos por linha. "Criado e depois apagado" e "apagado e depois criado" descrevem mundos diferentes.

E a captura não pode quebrar o caminho de escrita. Um mecanismo de captura que faz o salvamento de alguém falhar porque um consumidor está fora do ar piorou o sistema.

flowchart TB
  W["uma linha muda"] --> Q["quem mais precisa saber?"]
  Q --> S["índice de busca"]
  Q --> A["warehouse de analytics"]
  Q --> N["notificações"]
  Q --> P["sistemas parceiros"]
  W --> R["e nenhum deles pode quebrar a escrita"]

A armadilha da escrita dupla

O formato tentador é escrever no banco e publicar um evento, lado a lado:

course.update!(active: true)
EventBus.publish(:course_activated, course.id)

São dois sistemas, e nenhuma transação abrange os dois. O update pode ser confirmado e a publicação falhar, ou a publicação pode dar certo e a transação sofrer rollback. De um jeito ou de outro, os dois discordam, para sempre, sem erro em lugar nenhum.

Essa é a falha que o curso de nível Pleno "Padrão: outbox pattern" trata, e a captura de dados de mudança é a família de técnicas para evitá-la.

A ideia que todas compartilham é tirar os eventos do próprio registro do banco sobre o que aconteceu, em vez de publicá-los ao lado. Se o evento vem do mesmo commit que o dado, os dois não têm como discordar.

Do que trata este curso

Ele trata de quatro técnicas, e não de uma, com custos diferentes e buracos diferentes, e a habilidade está em escolher entre elas:

Polling de uma coluna de timestamp. Gatilhos que escrevem numa tabela de mudanças. Um outbox escrito na mesma transação. Captura baseada em log, lendo o write-ahead log.

A lição 2 compara as quatro, e o resto do curso trata dos jeitos como cada uma perde eventos.

Pontos-chave

• A captura de dados de mudança transforma as escritas no banco num fluxo que outros sistemas podem consumir.
• Três exigências puxam umas contra as outras: não perder nada, manter a ordem e nunca quebrar o caminho de escrita.
• Publicar um evento ao lado da escrita é uma escrita dupla. Os dois sistemas podem discordar sem erro nenhum.
• Toda técnica aqui tira os eventos do próprio registro do banco, então o evento e o dado dividem o mesmo commit.
• São quatro abordagens: polling, gatilhos, um outbox e captura baseada em log.