12.2. Change data capture e event sourcing
CDC transforma as escritas do banco num stream; o log vira a fonte, e o estado é sua integral.
Resumo
- Dual write (app grava no banco e no índice) causa divergência com corrida e falha parcial. Evite.
- CDC: ler o log de replicação do banco (Debezium) e publicar cada mudança; derivados seguem a ordem do banco.
- Início: snapshot + log a partir da posição dele. Compactação de log mantém o último valor por chave.
- Event sourcing: eventos da aplicação no nível de negócio ("reserva cancelada"), não linhas alteradas.
- Estado = integral dos eventos; o stream é a derivada. Imutabilidade ajuda auditoria e views novas, mas apagar dados exige cuidado.
Perguntas-chave
responda de cabeça, depois abraPor que dual write é perigoso?
Duas escritas concorrentes podem chegar em ordem diferente em cada sistema, e se uma falhar os dois ficam inconsistentes para sempre.
Qual a diferença entre CDC e event sourcing?
CDC extrai mudanças de baixo nível de um banco mutável; event sourcing modela a aplicação desde o início como eventos de negócio imutáveis.
Como apagar dados num log imutável?
Com compactação/tombstones, criptografia com chave descartável (crypto-shredding) ou reescrita do histórico; é preciso prever no desenho.
Exercícios de fixação
0/5 respondidas1.
A aplicação grava no Postgres e depois no Elasticsearch. Duas atualizações concorrentes deixam valores diferentes em cada um. Qual a solução indicada?
2.
Um evento "Assento 12A liberado pelo cliente" é típico de:
3.
Com compactação de log, um tópico CDC mantém:
4.
"O estado da aplicação é a integral do stream de eventos" quer dizer:
5.
Um usuário exige a exclusão dos dados, mas eles estão num log de eventos imutável. Qual técnica ajuda?