# Event Sourcing: O Modelo Mental por Trás da Linha do Tempo do Cliente

> Guardar "status do lead = qualificado" é um modelo. Guardar toda a sequência de interações que levou até ali é outro, bem mais poderoso. Entenda event sourcing e por que CDPs modernas são construídas assim.

- Tipo: Artigo
- Autor: Dionatha Rodrigues
- Publicado em: 2026-08-29 · Atualizado em: 2026-10-30
- URL: https://clubmartech.com.br/blog/event-sourcing-jornada-cliente/

Existem duas formas de guardar a informação de que um lead virou cliente. A primeira é atualizar um campo: "status = cliente". A segunda é guardar cada evento que levou até ali — visitou a página de preços, baixou o material, recebeu uma ligação, assinou o contrato — numa sequência ordenada e imutável. A primeira é como apagar o quadro e escrever só a resposta final. A segunda é guardar cada rascunho, cada rabisco, cada correção, na ordem em que aconteceram.

Esse segundo modelo tem nome: **Event Sourcing**. O padrão foi nomeado e formalizado por Martin Fowler em dezembro de 2005, como parte do seu catálogo de padrões de arquitetura corporativa, e desde então se tornou a base conceitual por trás de praticamente toda Customer Data Platform (CDP) moderna.

## A mudança de paradigma: de estado para evento

A forma tradicional de guardar dado — e a que a maioria dos sistemas usa por padrão — é persistir **estado**: uma tabela de clientes com uma linha por pessoa, e cada campo dessa linha reflete o valor *atual*. Quando algo muda, o valor antigo é sobrescrito pelo novo. Isso é simples e suficiente para a maioria das aplicações — mas tem uma consequência irreversível: o histórico de como se chegou ali desaparece.

Event Sourcing inverte essa lógica. Em vez de guardar o estado atual, o sistema guarda **a sequência completa de eventos** que aconteceram — e o estado atual deixa de ser algo armazenado diretamente, passando a ser *calculado* ao somar (ou "reproduzir") todos os eventos até aquele ponto. O log de eventos se torna a única fonte da verdade; tudo o mais é derivado dele.

## O exemplo mais direto: o carrinho de compras

O exemplo mais citado, e o mais próximo de marketing, é o carrinho de compras de e-commerce. Em vez de o carrinho ser uma tabela que diz "contém: 2 produtos, valor R$ 150", o sistema registra cada evento individualmente: "item A adicionado", "item B adicionado", "item A removido", "quantidade de B alterada para 2". O estado atual do carrinho é a soma de todos esses eventos, calculada no momento em que alguém precisa saber "o que tem no carrinho agora".

O Kafka — a plataforma de mensageria mais usada para esse tipo de arquitetura — atua como o "event store": o registro permanente e ordenado de tudo o que aconteceu. A partir desse fluxo de eventos, diferentes serviços consomem a mesma informação para propósitos completamente diferentes: um serviço de detecção de fraude analisa padrões de adição e remoção suspeitos; um serviço de cobrança calcula o valor final; um serviço de e-mail dispara um lembrete se o carrinho ficar parado por tempo demais.

![Quatro eventos do carrinho: adicionar A, adicionar B, remover A e mudar B para quantidade dois; a reconstrução resulta em dois itens B.](https://clubmartech.com.br/wp-content/uploads/2026/08/cmt-interna-28794-editorial.webp)

*O carrinho atual pode ser reconstruído a partir do que aconteceu. Modelo explicativo do conteúdo; consulte as notas e fontes na imagem.*

## A consequência mais importante: ninguém precisa concordar sobre o schema final

Esse é o ponto conceitual mais valioso do padrão, e o menos intuitivo à primeira vista: como os eventos brutos são a fonte da verdade, **cada serviço consumidor pode interpretar esses eventos à sua própria maneira**, construindo seu próprio modelo de dado otimizado para seu próprio propósito.

O time de e-mail pode interpretar "item adicionado ao carrinho" como um gatilho de campanha de carrinho abandonado. O time de BI pode agregar o mesmo evento numa métrica de intenção de compra por categoria de produto. O time de detecção de fraude pode olhar para a *velocidade* entre eventos como sinal de comportamento automatizado suspeito. Nenhum desses times precisa negociar um schema comum antecipadamente — cada um extrai do mesmo log bruto o que é relevante para si.

## Tradução direta para CRM e CDP

A diferença entre modelo de estado e modelo de evento é exatamente a diferença entre um [CRM](https://clubmartech.com.br/significado/crm/) tradicional e uma [CDP](https://clubmartech.com.br/blog/plataformas-dados-cliente-cdp-guia/) construída sobre event sourcing:

| Critério | Modelo de estado (CRM tradicional) | Modelo de evento (CDP moderna) |
| --- | --- | --- |
| **O que é guardado** | "Status do lead = qualificado" | Toda a sequência: visitou site → baixou material → abriu e-mail → recebeu ligação → foi qualificado |
| **Reconstruir o passado** | Impossível — o valor antigo já foi sobrescrito | Trivial — basta reproduzir os eventos até o ponto desejado |
| **Nova regra de segmentação** | Só se aplica a partir de agora, com dado futuro | Pode ser recalculada sobre todo o histórico já registrado |
| **Auditoria** | Exige log separado, muitas vezes incompleto | Nativa — o histórico completo é a estrutura de dado em si |

O modelo de evento permite reconstruir "como estava a nossa base em março?" com precisão, porque nada foi sobrescrito — só permite calcular novos estados a partir da mesma sequência bruta. Também permite recalcular segmentações inteiras com uma regra nova, aplicada retroativamente sobre todo o histórico, algo praticamente impossível quando só o estado final foi preservado.

## A trilha de auditoria como efeito colateral, não como projeto à parte

Um benefício frequentemente subestimado: em arquiteturas de estado, "trilha de auditoria" costuma ser um recurso adicional, construído separadamente e sujeito a lacunas — alguém esquece de logar uma mudança, ou o log de auditoria não cobre todos os pontos de entrada do sistema. Em event sourcing, a auditoria **é** a estrutura de dado — não existe uma "mudança que não foi registrada", porque toda mudança só existe na forma de um evento gravado.

Isso conecta diretamente com exigências regulatórias como [LGPD](https://clubmartech.com.br/blog/lgpd-transformar-compliance-tecnologia/), que frequentemente pedem rastreabilidade de quando e como um dado pessoal foi coletado, alterado ou usado — uma pergunta que o modelo de evento responde por design, e que o modelo de estado precisa reconstruir com esforço extra.

## O exemplo mais eloquente: o New York Times desde 1851

O caso mais citado de event sourcing em escala é o do New York Times, que armazena cada artigo, imagem e registro de assinatura desde **1851** como um event store — o log bruto e imutável de tudo o que já aconteceu na publicação. A partir desse log central, o jornal desnormaliza o dado em múltiplas "views" especializadas, alimentando diferentes índices de Elasticsearch otimizados para diferentes tipos de busca e análise.

O paralelo com [martech](https://clubmartech.com.br/blog/martech/) é direto: o log de eventos bruto (cada interação do cliente, desde sempre) é a fonte da verdade; os "views" especializados (segmentação para campanha, pontuação de lead, relatório de atribuição) são derivados dele, cada um otimizado para seu próprio uso, sem competir pela mesma estrutura de dado.

## O custo: "qual é o estado atual" deixa de ser trivial

Nenhum modelo de arquitetura vem sem custo, e este é o trade-off central do event sourcing: responder "qual é o estado atual deste cliente agora?" deixa de ser uma leitura direta de um campo e passa a exigir **projeção** — percorrer (ou consultar um resumo pré-calculado de) todos os eventos relevantes até chegar ao estado presente.

Na prática, sistemas de event sourcing maduros resolvem isso com *snapshots* periódicos — um resumo do estado calculado até certo ponto, para não precisar reprocessar tudo desde o primeiro evento a cada consulta — e com padrões complementares como [CQRS](https://clubmartech.com.br/blog/cqrs-leitura-escrita-separadas/), que separa explicitamente o modelo otimizado para escrita (gravar eventos) do modelo otimizado para leitura (consultar o estado atual).

É por isso que CDPs baseadas em evento são simultaneamente mais poderosas e mais complexas de operar que um CRM tradicional: o ganho de flexibilidade e histórico vem acompanhado de uma camada de engenharia adicional que precisa ser bem projetada para não sacrificar velocidade de consulta.

## Quando vale a complexidade

Event sourcing não é a escolha certa para toda operação. Ele se paga quando pelo menos uma destas condições é verdadeira:

- A operação precisa reconstruir estados passados com frequência — auditoria, compliance, ou análise histórica de jornada.
- Diferentes times consomem o mesmo dado bruto de formas genuinamente diferentes, e forçar um schema único geraria atrito constante entre eles.
- Regras de segmentação e pontuação mudam com frequência, e recalcular retroativamente sobre o histórico completo é um requisito real, não hipotético.

Para uma operação pequena, com um único sistema de verdade e baixa necessidade de reconstrução histórica, um CRM tradicional baseado em estado continua sendo a escolha mais simples e barata — trazer a complexidade de event sourcing sem o problema correspondente é custo sem benefício.

## Um teste simples para reconhecer o modelo por trás de uma ferramenta

Nem sempre o fornecedor usa o termo "event sourcing" explicitamente na documentação ou na conversa comercial, mesmo quando a arquitetura por trás é exatamente essa. Um teste prático e rápido para descobrir o modelo real: peça para visualizar o histórico completo de interações de um único contato específico, ordenado cronologicamente, desde o primeiro registro até hoje.

Se a ferramenta apresenta uma **linha do tempo detalhada** — cada visita, cada abertura de e-mail, cada mudança de status, na ordem exata em que aconteceram — é sinal de que o dado subjacente é guardado como eventos. Se a ferramenta só consegue mostrar "o estado atual" e talvez um resumo agregado ("5 visitas ao site, 3 e-mails abertos"), sem a sequência detalhada e cronológica de cada interação individual, é sinal de que o modelo por trás é de estado, não de evento — mesmo que o material de venda use a palavra "jornada do cliente" livremente.

## Próximos passos para avaliar sua CDP ou CRM

A ação concreta: pergunte ao fornecedor da sua CDP ou plataforma de dados de cliente se ela armazena eventos brutos e imutáveis, ou apenas o estado atual de cada contato. A resposta determina diretamente se você consegue, daqui a um ano, recalcular uma segmentação nova sobre o histórico completo — ou se só vai conseguir aplicá-la a partir de agora, com o passado perdido.

Se a resposta for "só guardamos o estado atual", isso não invalida a ferramenta para o uso presente, mas é uma limitação real a considerar antes de depender dela para qualquer análise que dependa de reconstruir "como era antes".