A gente criou um serviço ali, então, o desenho final do que está em produção é isso aqui. API Go na entrada. Cada microsserviço implementando o Pipes Framework. Ele está numa outra Instâncias Go também, com cada microsserviço específico aqui. Tem o microsserviço que faz o Fan- in. Só que agora, em vez de reescrever num outro tópico do Kafka, ele consome tudo e grava numa base Postgres, a gente está discutindo ainda sobre essa base Postgres virar uma base time series, que tem suporte a isso o timescaleDB dentro do Postgres, já que é um componente que a gente só vai fazer insert a vida toda, quase que log, não vai ter alteração dele, então a gente tem que ir entendendo se encaixa, se sim ou se não. 

E ali do solenoid, fazendo as buscas e tomando ações, ele só faz a ação de compensate. Hoje está implementada. Não tem a ação de retry ainda configurada, aquela que eu falei de: “poxa, como eu sei se, de repente, o tópico C só morreu?” Aquele componente, manda de novo. Retenta na estrutura. 

O resultado que a gente obteve quando subiu a estrutura: a gente teve zero erros dos que nós tínhamos antes. Então, isso foi muito legal. Em termos de aquela estabilidade do negócio, para falar com aquele cliente institucional, com o crescimento, todos os números que precisam. Nesse sentido, a gente conseguiu atingir bem. Não tem nada que pare completamente os sistemas. Tem erros, meus erros ficam isolados. A gente não tem interrupção de serviço. Tivemos alguns erros novos, mas isso é bom também. Então, a gente foi aprendendo com os novos erros já. A gente fez uma inversão de dependência lá com o monolito, porque aquela estrutura, como eu disse no começo, ela começava na API do monolito e escrevia na base dele. A gente continua escrevendo na base dele. Só que agora, escrever na base dele é um dos passos do Saga. E isso é mega importante para a gente porque a gente está num processo de vendo todas as formas de parar de escrever nessa base também. Então, quando a gente parar de escrever nessa base, só o que a gente tem que fazer é: edita aqui os passos e eu paro de chamar o passo que é o microsserviço que é na base do serviço. Eu nem preciso fazer um mega deploy complexo, ou apagar código inicialmente. Só para de chamar esse microsserviço, para de pôr nessa fila, eu já parei de escrever na base. Agora eu jogo fora esse código. Então, isso dá muito mais segurança para a gente fazer esse movimento, que já tem tempo que a gente quer fazer. 

Não era o objetivo direto aqui. Isso surpreendeu a gente, mas teve uma redução de em torno de 50% do tempo das operações. Isso é mega interessante, porque como eu falei, a gente começou com 5 microsserviços em cada endpoint, em cada ação que fazia API. E, então, você tem interação para caramba rodando. Chama o cluster. E a gente... Tudo por ser basicamente base de código nova. Sendo bem feita, bem pensada o código, a gente melhorou o tempo aqui. A gente conseguiu rodar, a gente queria fazer faz tempo, uma campanha para que clientes críticos migrem a versão de API que estão usando. Porque apesar de dar erro de vez em quando, o cliente não quer mudar se ele já está integrado com a API, mesmo que ela não funcione direito. Porque ele quer que você resolva qualquer outra coisa. E não que ele faça essa parte. A gente conseguiu mostrar que, a gente fez isso para a API nova, só, não para a API antiga. 

Então, a gente falou, migra para a API nova, você vai ter esses ganhos todos. E a gente definiu um padrão para tudo o que a transação distribuída na empresa. E a gente tem uns próximos passos aqui, nessa linha que são ter governança dos casos de uso. Como eu falei, a gente começou ali no código mesmo, nessa API eu sei que eu tenho esses passos, então vai desse jeito. Mas isso, agora, começou num segundo projeto também, isso para crescer mais,  a gente precisa ter um lugar central que olhe e organize isso. Eu tenho um caso de uso específico, e eu tenho esses passos, eu tenho esse tipo de rollback, eu tenho, para esse caso de erro nesse espaço eu vou ter tais opções, toda essa matriz que a gente possa gerenciar isso bem, com segurança do que está fazendo. Fazer a parte do retry, ou ter rotina de compensação aqui pelo stream do Kafka. Quando a gente tirou o KSQLdb, a gente perdeu o poder que tinha na nossa base. A base está diretamente no stream, então, a gente está ali ainda rodando uma “cronzinha”, então, a gente perde alguns segundos para fazer o rollback, ainda. Não é crítico, mas precisa melhorar. Suportar RabbitMQ ou qualquer outro broker, que seja o caso aqui.

Vem uma discussão interna que está tendo, se vai usar Kafka para tudo, se sim ou se não. Porque, o jeito como a gente fez ali o Pipes é uma abstração também. Qual é o... Quem é a mensageria? Então, eu posso implementar aqui. Colocar o driver, fazer os testes. Mas não importa. Se eu for para o Rabbit, eu vou ter os mesmos três tópicos: .in, .compensante e .error. Eu vou ter também um outro componente fazendo um Fan-in de tudo isso e chegando em uma base, então assim, é essencialmente a mesma coisa no papel. A gente tem que implementar e rodar, achar quais são os limites para essas coisas, mas qualquer que seja o caminho aqui, a gente consegue ter uma versão também do framework para Python e Java, que são outras linguagens muito usadas lá dentro e por fim migrar outras transações legadas, que a gente acha que precisa migrar para cá. Como o Wesley falou no começo, nem tudo precisa vir para esse modelo, mas tem outros casos que fazem sentido trazer. A gente deve olhar para eles com carinho no ano que vem.  Já tem muita coisa antes de chegar nessa fase então. 

Era isso, a ideia aqui, o ponto. E vamos para a próxima parte. Falei disparado aqui. Se deu para acompanhar alguma coisa é para o papo.