Mas a gente pensava: o que vai ser essa base? Vamos ter um microsserviço que conectam em tudo? Sim ou não? O que fazer? 

(Isso está no próximo slide, puxou alguma coisa errada) 

Antes, ainda na coreografia, a gente pensou num ponto importante: isso aqui abre uma possibilidade para gente muito interessante, sobre aquela questão de ter clientes diferentes, públicos diferentes. Naquele exemplo que eu mostrei antes, aquele  serviço A fazia uma função estritamente de gestão de risco. E aquele cliente 24/7 tem o contrato para operar com a gente. Ele está aqui. Ele tem que fazer várias transações por segundo aqui e tudo mais. E, assim, todo  microssegundo importa. Então, e se, já que ele já tem contrato, eu abrir mão de fazer algumas validações de risco, porque eu confio nesse cliente. Eu tenho um relacionamento próximo com ele. Isso faz todo sentido, e  nós validamos isso com a área de negócios. Nem sei porque tem esse negócio aí .Você não sabe porque é para fazer retail, mas tudo bem. 

A gente pode definir, então, a ideia de que, nessa coreografia, por exemplo, eu possa chamar aqui o step A e o step C sem passar pelo step B? Pode. E é bem o que está descrito aqui, pois temos um caso de uso 1.1 e 1.2 com essas micro variações, mas que são essenciais na hora que a gente for cumprir alguns contratos, ter algumas coisas específicas. 

Eu estou falando disso, mas entenda que, isso é uma prática comum de mercado, inclusive. Você tem faixas de clientes diferentes, que você vai tratar diferente de acordo com o relacionamento, coisas desse tipo. E a gente estava pensando numa solução tecnológica que pudesse suportar isso, sem espalhar um monte de if, um monte de sistemas. Porque eu poderia dizer: nesse caso de uso, eu nem vou passar naquele microsserviço. Eu nem vou passar naquela fila.

Com relação aos estados: a gente achou o ksqlDB. Assim, vendo e  estudando  mais sobre o Kafka, que ele é um banco de dados que literalmente se conecta ao Cluster Kafka e já prepara umas views para você consultar e tudo mais, faz um MapReduce.  

Os problemas estavam resolvidos. Vamos alocar esse cara, nem precisa pensar nessa parte porque já tem um banco de dados pronto que conecta lá. E o ponto chave da parte do Saga, a gente volta para ele… como a gente deu um passo atrás em termo de padronização, a gente precisa estruturar bem os nossos tópicos, os microsserviços, as nomenclaturas e tudo que dá produção, as esteiras. A gente criou aqui uma ideia que vai ter uma semântica no nome do tópico e, quando coloca ele no tópico, eu já sei que não precisa ficar chamando, o microsserviço está ali, o domínio, o subdomínio daquela interação.  

E um ponto mega importante do tipo que tem… O tipo é o segredo do que a gente implementou de fato, que é basicamente todo microsserviço ali ter três tópicos. Tem um tópico .in que é onde vai receber as mensagens de progressão quando as coisas estão dando certo (do A para o B, do B para C). O .compensate que é para o rollback ( então ele pode ser do C para o B, do B para o A). E o de error com uma Dead Letter Queue (para a gente poder depois olhar, entender o que aconteceu ali, inclusive ter a mensagem ali fácil para reinserir ou na .in ou na .compensate).

E como aquela parte simplesmente sabe o próximo passo que é para chamar, sabe para onde vai? A gente resolveu isso dentro da estrutura da mensagem, que vai nas filas. Coloca o payload no body, normal,  e colocou uma área no JSON das mensagens um meta… os metadados com “global-id”. Então, a parte aqui, ID único, 1, ou ela é ID que a gente colocou aquela parte para saber: “olha, essa transação, onde ela está. Eu estou buscando esse ID em todas as filas, onde ele passou.” 

E uma chave com uma lista de quais são passos para serem cumpridos naquele caso de uso. Então, a primeira, no próprio caso a API do INIT, já estava aqui nele, primeira versão hardcoded. Você vai colocar no step 1, no seu caso é esse, e manda lá; step 1, 2 e 3. Na fila de coisas. O step 1, quando consome, fala: “opa, eu sou step 1, estou aqui nessa posição da lista”. Faz o que tem que fazer, pública na fila step 2.in. O step 2 consome também: “opa, eu sou o step 2”. Ele vai lá, faz o que tem que fazer e pública Step 3.in. O step 3, caso dê um erro de negócio, alguma coisa, sei lá, um erro 400, se fosse só uma API direta, ele fala: “legal, faz rollback quem está antes de mim.” 

O que é o faz rollback então? O passo… ele vai pegar a lista que ele tinha de passos, que era passo 1, 2 e 3. E ele é o 3, então, exclui o resto da lista, inverte a lista e manda:  “Opa! Step 2 compensate”. Por puxar da fila .compensate, a rotina já vai saber que tem que fazer rollback. Rollback lógico, faz o que tem que fazer e manda para o próximo passo da lista que é o step 1 compensate.

Foi assim que a gente resolveu a questão do ir e voltar nessa estrutura da forma na coreografia e a coisa sabe qual é o próximo passo.