Descomplicando Event Sourcing
Recentemente estava consumindo conteúdo sobre o princípio de CQRS (Command Query Responsibility Segregation) e acabei esbarrando no sujeito que compõe o título deste artigo, cuja ideia achei muito interessante.
No final dessa leitura, espero que fique mais claro o que é Event Sourcing e que a imagem do snowboard que eu selecionei no início faça mais sentido também, pois demorei uns 10 minutos para escolher ela…
Event Sourcing?
De maneira simples o Event Sourcing é uma coleção de padrões e conceitos usados para garantir que cada mudança no estado de um sistema seja capturada em um objeto de evento e que esses objetos de evento sejam armazenados na sequência em que ocorreram.
Com essa sequência de dados podemos fazer várias coisas, mas duas delas que podemos perceber de cara é a possibilidade de realizar replay ou revert dessa sequência de ações a partir de qualquer um dos eventos.
É importante notar que quando falamos de Event Sourcing estamos nos referindo a uma sequência de eventos que, uma vez que foram amarzenados, nunca devem ser apagados ou atualizados.
Para ser um pouco mais flexível, existirá circunstâncias onde vamos querer apagar dados muito antigos e isso é, em certa medida, aceitável.
Porém, conceitualmente falando, em sistemas que utilizam Event Sourcing, nunca deveríamos apagar um registro de evento, pois muitas vezes não é possível nem mesmo sabermos como estará o domínio em que estamos trabalhando daqui dois ou três anos e quais serão suas novas exigências — isso irá ficar mais claro com o exemplo da Amazon que darei mais a frente.
Em determinados domínios apagar eventos é até mesmo inaceitável. Já imaginou um médico tendo a possibilidade de apagar algum registro do histórico de um paciente?
A primeira vista a ideia de armazenar todas essas informações por um longo período de tempo pode nos parecer custoso do ponto de vista financeiro, mas você ficaria impressionado com a quantidade de informações sobre eventos que podemos armazenar em apenas 1 GB.
Muitos de nós falamos sobre gastos com armazenamento sem ao menos termos uma quantidade realmente significativa de transações diárias em nossos sistemas.
O próprio Greg Young, quem começou a conversa sobre Event Sourcing, disse a seguinte frase em uma de suas palestras (em tradução livre):
“.. se eu puder pegar todos os dados da sua aplicação que está rodando há um ano, e conseguir colocá-los em um microSD, você não é big data. Sabendo disso, deletar dados deve ser descartado de suas preocupações por hora…”
Uma dica que pode nos dar uma boa ideia se devemos nos preocupar em deletar os dados antigos ou não quando estamos aplicando Event Sourcing é a lei de Moore.
De forma resumida, se o seus dados não estão crescendo mais rápido que a curva exponencial apresentada pela lei então provavelmente você não terá problemas de armazenamento.
Vantagens
Vou pontuar neste artigo apenas as vantagens do Event Sourcing, mas isso não significa que ela seja perfeita para todo e qualquer caso. O Event Sourcing usado de forma imprudente pode aumentar a complexidade de um sistema ou mesmo arruinar um projeto inteiro.
Em linhas gerais o conceito de Event Sourcing é simples, mas a sua aplicação deve ser feita de forma criteriosa, entendendo se todos os casos de uso serão realmente cobertos pela sua modelagem de dados e como realmente os usuários finais irão utilizar tais dados — não somente como irão armazená-los ou gerenciá-los.
1) Rastreio
Em sistemas que não utilizam Event Sourcing, eventualmente acabarão com o estado de seus objetos alterados sem possuir os registros que indicam quais caminhos foram tomados para resultar em tal estado.
Um exemplo usado por Martin Fowler para explicar Event Sourcing é o de notificação de embarque/desembarque que pode ser encontrado aqui.
No exemplo em questão, temos os seguintes acontecimentos:
- O navio ‘King Roy’ saiu de San Francisco
- O navio ‘Prince Trevor’ chegou em Los Angeles
- O navio ‘King Roy’ chegou em Hong Kong
Em um sistema que não utiliza Event Sourcing teríamos os dados representados assim:
Observe que temos apenas o estado final dos nossos registros. Não sabemos o que levou o primeiro navio “King Roy” a chegar em Hong Kong. O mesmo acontece com o navio “Prince Trevor” de Los Angeles.
Em contrapartida utilizando Event Sourcing ficaríamos com os seguintes registros:
Nesse novo modelo podemos, por exemplo, fazer buscas em nossa base de dados pelo navio ‘King Roy’ para rastrear por onde ele passou nos últimos três anos.
Obviamente, a arquitetura para chegarmos nesse resultado seria mais complexa como podemos ver a seguir:
2) Novas features sobre eventos antigos
Outra grande vantagem em utilizar o Event Sourcing está na capacidade de adicionarmos novos recursos que irão impactar não apenas novos registros a partir de sua implementação, mas também registros antigos. Vamos dar um exemplo mais concreto para exemplificar isto.
Vamos imaginar que somos um desenvolvedor da Amazon e nosso especialista do produto diz que teve um insight sobre as compras realizadas no site.
Ele percebeu que em algumas situações, cinco minutos antes da finalização do pedido, o usuário remove alguns itens do carrinho de compra.
Sabendo disso seria interessante passar a apresentar esses itens que foram removidos como sugestão de produtos para o usuário ao invés de mostrarmos produtos aleatórios.
Em uma aplicação comum teríamos que fazer uma série de modificações no sistema para que conseguíssemos alcançar tal resultado.
Também não seríamos capazes de gerar propagandas para compras realizadas antes desta nova implementação, pois passaríamos a persistir a informação de que o item foi removido apenas após a criação do novo recurso.
Mas imaginando um cenário em que nosso sistema já utilizasse Event Sourcing, naturalmente teríamos as informações de remoção de item do carrinho registrado em nossa sequência de eventos.
Com isso teríamos apenas que comparar o momento em que ocorreu o evento de remoção com o momento de finalização do pedido para garantirmos que encaixaria na regra dos 5 minutos.
Bônus: Poderíamos habilitar esse novo recurso para funcionar mesmo para compras antigas.
3) Testes
Com os eventos registrados, podemos simulá-los através do replay da sequência de suas ações em nossos testes.
Isso nos permite realizar smoke tests de maneira mais fácil e assertiva, uma vez que iremos colocar a prova a nova versão do sistema processando todos os eventos que até então funcionaram corretamente em versões anteriores do software. Esses testes podem ser feitos progressivamente com o uso do sistema.
Por exemplo, podemos comparar o histórico da última semana de execução do meu sistema (versão de aplicativo atualizada) com o histórico da penúltima semana (versão de aplicativo desatualizada).
A partir dessa comparação analisaremos se houve alguma mudança inesperada no comportamento da aplicação após o update.
4) Machine Learning
Acaba sendo explícito os benefícios para a implementação de machine learning em sistemas que utilizam Event Sourcing.
Um algoritmo em particular que funciona muito bem nesse cenário seria o conhecido como Alpha Beta Training, onde Alpha é o primeiro elemento de um event stream e o Beta o décimo primeiro. Nesse caso, o trabalho de Alpha seria prever o valor de Beta.
Conclusão
A ideia do Event Sourcing é muito poderosa e bem-vinda em situações onde se pede o rastreio de eventos ou mesmo em negócios onde queremos ter a flexibilidade de adicionar novas funcionalidades baseadas em tais eventos.
Espero que tenha ficado um pouco mais claro sobre o que se trata a ideia do Event Sourcing. Até a próxima!
