Event sourcing e CQRS são dois padrões que têm crescido na comunidade do Domain-Driven Design (DDD). Em sua apresentação na Conferência Européia de Domain-Driven Design, Martin Kleppmann comparou o event sourcing com o processamento de streams e observou que o processamento de fluxo é baseado em ideias similares, apesar de ter surgido em comunidades diferentes.
Kleppmann, que possui experiência na construção de sistemas de dados em alta escala para empresas de Internet, mas que atualmente está na Universidade de Cambridge, nota que ao comparar software empresarial com sistemas de empresas de Internet, a principal diferença é onde a complexidade está localizada. Do lado do software empresarial, a complexidade é baseada em domínios e regras de negócios. Nas empresas de Internet, os domínios são relativamente mais simples. No entanto, possuem um grande volume de dados chegando em uma alta velocidade, trazendo a complexidade para a infraestrutura de dados. Apesar de existir complexidade em ambos os lados, por várias razões, Kleppmann descobriu que o event sourcing nos softwares empresariais é similar ao processamento de streams, ou à sequência de eventos imutáveis, no software de empresas de Internet.
Uma ferramenta para manusear streams com o qual Kleppmann esteve envolvido, é o Kafka que originalmente foi desenvolvido para juntar arquivos de log e processamento de eventos e é baseado em uma premissa muito simples: comparar com um arquivo de log em que novas mensagens ou eventos são anexados. Isso, cria uma sequência ordenada de registros que, no geral, podem tratar qualquer fluxo de eventos. Uma funcionalidade significativa do Kafka é sua capacidade de tratar grandes volumes de dados distribuídos em múltiplos servidores.
Uma implementação interessante usando a ferramenta Kafka que Kleppmann pensa ser muito parecida com o event sourcing é a utilização do fluxo de eventos correspondentes a alterações em um banco de dados em que um evento é gerado para cada registro atualizado no banco de dados, por exemplo, como resultado da atualização de uma entidade. Desta forma, um consumidor pode ler eventos à medida que são publicados e aplicá-los à sua versão local dos dados. Kleppmann observa que este caso de uso é similar à replicação em banco de dados em que escritas no banco de dados principal são replicados para uma réplica do banco de dados.
Originalmente, o Kafka foi desenvolvido para casos de uso nos quais perder uma porcentagem das mensagens é aceitável, mas com a experiência de operação e maturidade, a expectativa de durabilidade aumentou de forma que o sistema de replicação atual está no mesmo nível de muitos sistemas de replicação de bancos de dados relacionais. Atualmente, a equipe de desenvolvimento do Kafka trabalha para adicionar suporte a transações permitindo a publicação de mensagens em muitas partições atomicamente.
O que Kleppmann acha mais interessante ao comparar event sourcing com processamento de streams é que essas duas ideias similares apareceram em duas comunidades muito diferentes. Isso sugere que podem haver ideias fundamentais que tornem essas tecnologias ainda mais importantes.
Em sua apresentação no QCon Londres, Kleppmann falou sobre usar Fluxo de Eventos e Kafka para manter dados sincronizados por meio de sistemas heterogêneos. Os slides da apresentação de Kleppmann estão disponíveis em seu blog.