[JJaeger]

programação por sockete geralmente tende a ser complicada... aqui nois usa java com spring boot, não sei a viabilidade disso. Sei que é mais fácil num node.js ou python da vida.

e pra gerar relatório com isso, como eu relaciono os dados de tantos micro serviços? deve ser um trampo, já que cada um tem seu bd próprio.

[Amagami]

programação por sockete geralmente tende a ser complicada... aqui nois usa java com spring boot, não sei a viabilidade disso. Sei que é mais fácil num node.js ou python da vida.

e pra gerar relatório com isso, como eu relaciono os dados de tantos micro serviços? deve ser um trampo, já que cada um tem seu bd próprio.

Para montar relatório você pode se basear nos Eventos.

Facilita bastante para a equipe de Data Science, na verdade. Você perde muita informação no modelo convencional, onde só armazena o estado atual das coisas. Agora você pode ver exatamente o que tá acontecendo, já que cada ação é um evento.

Você vê que tem uma certa tendência do usuário em comprar 5 unidades de um produto X. No modelo de eventos você consegue ver que ele adicionou 8 no carrinho, mas no checkout removeu 3. Será que o frete tava caro demais? Vamos tentar reduzir o frete e estudar se isso continua acontecendo.

[JJaeger]

Para montar relatório você pode se basear nos Eventos.

Facilita bastante para a equipe de Data Science, na verdade. Você perde muita informação no modelo convencional, onde só armazena o estado atual das coisas. Agora você pode ver exatamente o que tá acontecendo, já que cada ação é um evento.

Você vê que tem uma certa tendência do usuário em comprar 5 unidades de um produto X. No modelo de eventos você consegue ver que ele adicionou 8 no carrinho, mas no checkout removeu 3. Será que o frete tava caro demais? Vamos tentar reduzir o frete e estudar se isso continua acontecendo.

cara, legal isso aí. Me lembrou um pouco o sistema de subscribe para alteração de dados de coleções do firebase, que eu acho foda pra caralho.

se surgir a oportunidade eu mando essa num projeto que tamo desenvolvendo, vai depender da opinião e do taco dos estagiários. Eu acho mais fácil dividir o trabalho dessa forma que todo mundo trabalhando numa branch própria num monstro enorme (spring boot).

foda que acho que essa arquitetura só fica boa com node ou python, a maioria do back aqui só usa java.

[Amagami]

cara, legal isso aí. Me lembrou um pouco o sistema de subscribe para alteração de dados de coleções do firebase, que eu acho foda pra caralho.

se surgir a oportunidade eu mando essa num projeto que tamo desenvolvendo, vai depender da opinião e do taco dos estagiários. Eu acho mais fácil dividir o trabalho dessa forma que todo mundo trabalhando numa branch própria num monstro enorme (spring boot).

foda que acho que essa arquitetura só fica boa com node ou python, a maioria do back aqui só usa java.

O mais legal do event sourcing é que de fato não existe informação demais, mesmo para empresas gigantes armazená-las quase nunca é um problema.

Isso resolve problemas demais.

Um outro exemplo é: vamos adicionar uma feature nova. Vamos mostrar na sidebar produtos que o usuário já teve interesse em comprar (adicionou ao carrinho mas removeu no checkout) na esperança que ele veja e tente comprar novamente.

O que vai acontecer? Vai ficar em branco nos primeiros dias, pois é uma feature nova e você não tem esses dados. Só vai começar a funcionar a partir do dia que for lançado em produção.

Com event sourcing você pode dar replay nos eventos para popular esse banco de dados de "produtos que você removeu do carrinho". Isso vale para qualquer feature nova que você for implementar.

[JJaeger]

tu tem algum artigo mostrando isso na prática com alguma linguagem? (que não seja ruby)

[Amagami]

tu tem algum artigo mostrando isso na prática com alguma linguagem? (que não seja ruby)

Não conheço muitos exemplos práticos não, mas é algo meio que independente da linguagem. Primeiro você tem que entender a teoria por trás disso, entender qual é o problema em primeiro lugar para conseguir entender a solução.

Aquela sua pergunta sobre o "feedback" foi muito boa. Tem várias outras complexidades também, como a ordem dos eventos e como garantir "transações" (se o pagamento não foi autorizado, você deve retornar o estoque e desfazer outras coisas que foram feitas em outros microsserviços). Tem várias abordagens para resolver esses problemas.

Depende muito das particularidades da empresa e do domínio. É um tema que casa muito bem com Domain-Driven Design.

[JJaeger]

hm... eu gosto sempre de ver um hello word das coisas pra tentar entender o mínimo que o sistema precisa pra funcionar.

vou caçar alguns artigos depois, mas se for muita teoria é altas chances de eu nem ler.

[Amagami]

hm... eu gosto sempre de ver um hello word das coisas pra tentar entender o mínimo que o sistema precisa pra funcionar.

vou caçar alguns artigos depois, mas se for muita teoria é altas chances de eu nem ler.

É que independe da implementação, não tem nada novo.

Um exemplo simples:



Para isso funcionar escreve qualquer código que publica algo no Kafka, depois escreve um serviço com qualquer código/linguagem que lê essas mensagens e vai atualizando no seu banco a tabela Account.

---

Não precisa ser Kafka. Para ficar ainda mais simples, imagina uma tabela "events" que é read-only. Você lê ela e replica em outra tabela "accounts".

[JJaeger]

É que independe da implementação, não tem nada novo.

Um exemplo simples:

Spoiler: Imagem   

Para isso funcionar escreve qualquer código que publica algo no Kafka, depois escreve um serviço com qualquer código/linguagem que lê essas mensagens e vai atualizando no seu banco a tabela Account.

---

Não precisa ser Kafka. Para ficar ainda mais simples, imagina uma tabela "events" que é read-only. Você lê ela e replica em outra tabela "accounts".

então, os dados só evoluem? não sei se eu entendi, mas os dados nunca sobrescrevem, eles só se transformam em novas instâncias. Se for isso mesmo não tem bd que aguente.

[Amagami]

então, os dados só evoluem? não sei se eu entendi, mas os dados nunca sobrescrevem, eles só se transformam em novas instâncias. Se for isso mesmo não tem bd que aguente.

Você pode manter apenas o estado atual no banco de dados de cada microsserviço. Inclusive cada banco de dados pode armazenar a mesma informação de maneira diferente, essa é a ideia do Domain-Driven Design. Cada parte da sua lógica de negócio funciona diferente, e cada entidade tem um significado diferente para cada parte dela.

O serviço de calculo de frete e logística não tem nenhum interesse em saber o nome do produto, nem a descrição dele. Muito menos a foto dele. Para esse serviço, um produto só tem dois dados: um lugar onde ele está (em qual estoque da empresa) e o seu peso. Assim ele pode dividir a compra em pacotes diferentes se estiverem em lugares diferentes e enviar para o cliente.

Não sei se consegui explicar bem, mas você pode armazenar a informação da forma que ficar mais fácil de ler para aquela parte do negócio.

Mas os eventos são imutáveis, eles NUNCA são deletados e jamais são alterados.

Isso não é um problema, eles nem ocupam tanto espaço assim. Bancos de dados foram feitos para armazenar volumes de dados gigantes. Os grandões podem ter instâncias do Kafka com petabytes de dados.

O Nubank armazena seus dados em um banco parecido com o git, Datomic. Nada nunca é sobrescrito, os dados só evoluem com o cursor do tempo. A empresa já tem 6 anos e o banco de dados nem cresceu tanto assim.

---

Olha ai, git é um bom exemplo de event sourcing.