[W] Show! Grande talk. Oh, Rafael, eu tenho alguns pontos aqui depois. Se o pessoal também quiser tirar alguma dúvida, por favor, coloquem as dúvidas no chat, que eu vou lendo e a gente vai discutindo.

E eu acho que o primeiro ponto que eu tenho é, vocês queriam, de uma forma geral, dar a sensação de sincronicidade com o usuário final, porém, utilizando, de forma geral, ações assíncronas, porque você também garante muito mais resiliência em saber tudo o que está acontecendo. Hoje, quando isso está acontecendo, o usuário final, de forma geral, teve esse ganho? Ele consegue ter essa percepção do que vocês estavam querendo colocar? Porque, no final do dia, o que importa é o usuário feliz lá na outra ponta, independente de tudo o que vocês fizeram. Como isso ficou na ponta do usuário final?

[R] Ainda não ficou. A gente tem um desvio, que a gente tomou, que foi uma decisão complicada. Aliás, tem em partes, mas a gente quer oficializar o assíncrono. Mesmo naquela nova API, a gente começou a olhar e falar: tem que ter uma espera. A assinatura continua sendo o lance do síncrono. Tem um padrão de mercado para essa parte de corretoras, bolsas, a gente usando mais stream, seja um WebSocket ou protocolo... esqueci o nome do protocolo. Tem que trabalhar com SSE, Server-Sent Events. É, alguma coisa do gênero que é para o cara realmente... O cara que está ali muito rápido, ele só manda e na outra ponta está no canal aberto sabendo se deu bom ou se deu ruim. Então, a gente está no meio do caminho. A gente manteve ainda um... A gente foi tentando fugir, mas para a primeira versão colocou um outro polling, só que em outro sistema mais isolado e melhor feito dessa vez para não bloquear tudo. Mas, o próximo passo é a gente conectar também a saída direta do que está na mensageria como rollback para manter a segurança do síncrono. Mas a gente está do outro lado com uma galera na campanha pelo assíncrono: “gente, assíncrono é bom, assíncrono é pop, assíncrono é legal. Vamos ser assíncrono todo mundo.” Desde a API, para API virar realmente de promessa. Volta em 201 e pergunta na outra ponta. Só que para aquele cliente muito grande tem o problema de que vai funcionar melhor para ele, na verdade… tudo bem a API não dar resposta, se ele tiver resposta no canal aberto, porque ele vai ganhar tempo. O cliente precisa fazer, tipo, algumas centenas de operações por segundo, gastar o tempo ali de handshake e tudo mais, para ele perguntar o estado, também é ruim para ele. Só que o interessante é que do jeito que o meu cliente cresceu, isso é ruim para esse cliente. Só para esse… 

[W] O cliente inteiro, quer saber ali na hora. Para ele é muito melhor.  

[R] Para outra galera, quem usa o app, o site e tudo mais, a gente consegue usar outras técnicas para deixar… não deixar isolado o servidor. E fala: “beleza, você faz um outro porque você tem…” A gente pegou, estatisticamente falando, assim, a gente pegou, assim, 99 pontos, sei lá, 9% das vezes que você acabou de fazer, você fez a próxima requisição para listar as ordens das coisas, aquilo está pronto já. Para a parte de app e para o site, a princípio, para a gente, funciona bem. Isso aí. Se vira e você pergunta de novo. Está dentro de casa mesmo, porque você pega a maior parte, a maior cardinalidade da base. A base, aquela específica que seja de tempo muito baixo e tudo mais, a gente tem que ver as soluções específicas para isso. E esses caras, a gente está considerando de inverter um pouco as coisas, ou abrir mais a porteira, e trazer eles para uma camada mais para dentro ainda. E talvez deixar eles em uma API depois que, de algum jeito, fique o mais perto da infra como um todo. E, de novo, sendo um cara grande parceiro com um contrato fechado e tudo mais, a gente pode abrir mais um pouco da caixa preta para eles para mostrar: “oh, a gente está fazendo exatamente isso daqui, então, se eu te posicionar aqui nesse lugar desse jeito, você vai ter esses ganhos.” E, mostrando os ganhos todos na prática, os caras topam. Então foi um pouco do que a gente fez, a gente está no meio do caminho, na verdade.

Os tempos, em geral, melhoraram. A gente teve feedback dos próprios clientes grandes migrando para a versão nova da API. Os caras elogiando de sentir a melhora no tempo de resposta como um todo e na própria estabilidade por si só. A gente teve até alguns incidentes acontecendo, como a semana passada teve um bem feio na versão antiga que não foi de propósito, mas ficou parecendo ser uma questão de obsolescência que a gente estava fazendo, assim. A gente falou: “eu juro que não foi, assim, mas foi, ficou muito estranho. Porque a gente mandou num dia a comunicação:  “muda para a nova versão. É muito mais estável e tudo mais, e caiu. E caiu a antiga, vai para a nova que o negócio vai funcionar. Uma ironia.”

[W] Agora, assim, depois eu quero falar um pouquinho mais sobre esses pipes, assim, eu gostei bastante da ideia e de como vocês definiram aquela interface. Na minha opinião, ficou muito simples de qualquer pessoa que vai trabalhar conseguir entender o que ele processa e faz o handle, se não, ele faz o compensate. É muito parecido com quando qualquer pessoa quer fazer uma migration no banco de dados. E você tem o migration up e o DAO, então é basicamente a mesma coisa que vocês estão fazendo. O que me deixou, na realidade, mais curioso de tudo e que, tecnicamente falando, posso estar mega enganado, mas tecnicamente falando, o que me deu a impressão que a grande dor de resolver esse problema, depois que você já modelou a solução, é ter criado o sistema monitor lá, o solenoid, sei lá como é o nome que vocês deram. Porque esse cara fica vendo todos os erros e eu posso falar: “olha, se for esse erro dá um retry, agora se for esse, ferrou vai para o slack do pessoal.” Como esses caras… o quão complexo foi para desenvolver esses caras nesses casos?

[R] Está saindo ainda. Vamos lá. A parte boa é que a gente estava tão debruçado nos primeiros problemas, que a gente sabia exatamente o que estava querendo mapear. Então, o que a gente precisou trazer ali, que não entrou no detalhe, é a gente está trabalhando ainda para evoluir sobre qual padrão usar de código de erro. Aquilo, são números mágicos? São strings? O que são? A gente tem aquela discussão, papo de barco, o* tempo todo. Mas a gente começou então com isso, com uma string de erro padronizada e a gente tinha… eu tenho esse passo que ele está muito bem definido, qual é o microsserviço aqui, e eu já espero que ele tenha esses erros. Então, a gente tinha: o conjunto de erros já muito claro no começo. E a primeira versão também, hardcoded.

[W] Tem muita coisa. O erro com string é essa, a gente já sabe o que fazer. Mais ou menos isso.

[R] É. E o hardcoded porque, bom, primeiro que funciona. A gente já consegue fazer o code review ali e a gente segue um pouco a linha de… Tudo que é muito genérico a gente tem a... Se eu tentar fazer genérico de cara, tipo, modelar uma base muito para muitos de todas as coisas eu posso fazer qualquer coisa, vai ficar difícil para caramba de se achar e a gente vai fazer errado, com certeza. Então, a ideia do... A gente partiu desse mapa bem definido e já deixou ali num JSON de configuração, mas o JSON está ainda no arquivo config, lá dentro, direto, na primeira versão para começar a fazer.

A partir daí, o que a gente começou a discutir foi: que base a gente vai usar para isso agora, para publicar isso daqui? Colocou numa base post dele também, ainda seguindo um JSON, e naquela API dele, a gente passou a seguir a mesma semântica, de colocar, eu posso cadastrar a ação. Então, fala, nesse microsserviço, esse string de erro que vem aqui no error, você faz tal ação. E os comandos do handle, se é um retry, se é o compensate, ou se é só um... Isso aqui sempre vai para uma fila de backoffice porque isso não se resolve sistemicamente. Tem algum outro problema que eu preciso de gestão manual. É esse o estado que a gente está dele agora. E a gente está olhando para: como a gente vai fazer isso escalar de verdade? E a gente não tem a resposta ainda. Escalar agora, no ponto de vista de escalar para a companhia. Porque, assim, a gente vai ter um mini comitê em tecnologia para fazer a curadoria disso daqui, e vai entregar já de uma ferramenta para alguém cadastrar as coisas, se cadastrar errado, o que faz.

[W] É porque se todo mundo começar a utilizar todos esses pipes, todo mundo… porque hoje você tem, sei lá, um sistema rodando isso. Quando tiver um monte de sistemas, você vai ter um monitor tomando conta de um monte de contextos diferentes. E o que acontece? Esse é o grande ponto.

[R] O que a gente já pensou de possíveis abordagens. E a gente está ainda tendo mais conversas para ver o que faz sentido saber. É quase… esqueci qual era o povo lá na Grécia Antiga que discutia uma coisa sóbria e bêbado para ver se fazia sentido ainda. É quase isso. Algumas discussões, a gente já imaginou de ter por caso de uso para isso escalar melhor. Então, por exemplo, falando de ações claras, eu tenho um caso de uso claro, que é tudo que envolve trading. Criar, cancelar ordem, essas coisas. Eu vou ter outro caso de uso, sei lá, para cadastro. Porque no cadastro eu tenho outros passos, eu tenho outros cuidados ali no que eu estou fazendo. Então, talvez, talvez faça sentido alguma estratégia de eu ter clusters desse cara focados: esse deploy, esse conjunto aqui, ou esse único cara hoje trabalha como um só para um conjunto, se paralisar não vai dar problema. Talvez ele tenha que continuar sendo um cara só, olhando para um conjunto de fila, um caso de uso. Mas olha, para tudo que é trading, tem esse cara aqui que vai cuidar.

Agora, o que é cadastro, outras coisas, que são outros tópicos, essencialmente, outros domínios de tópico, eu tenho outra instância, outro deployment para olhar para isso. Esse é o mais provável que a gente entende que vai chegar em um grau de escala bom em termos de tempo e também do ponto de vista de segurança, de eu não embananar as coisas ali e eu ter alguma, sei lá… vamos supor o trading é o melhor caso, porque a gente processa milhões de ordens por dia. Só que eu tenho, sei lá, e talvez com campanhas ativas eu vou ter até 15 mil cadastros no dia. Então, assim, eu misturar essas coisas, porque eu posso ter alguns detalhes de otimização para trading que eu não preciso para os outros. Ao mesmo tempo eu não quero que outros casos de uso interfiram no que eu estou fazendo de trading. Então, o mais provável de escala que a gente vai ter no futuro é esse de separar em conjuntos.

Da mesma forma, o próprio plano de escala, dentro do próprio Pipes, também a gente prevê isso, porque a gente entrou nas entranhas do Kafka, sobre escala, e as partições, e o paralelismo, e tudo mais que a gente precisava fazer. A gente falou: “cara, a gente olha para que a gente tem listado, sei lá, 200 moedas, nos mercados diferentes, e vai aumentar.” Não é todo mercado que frita o tempo todo. Então, a minha escala é diferente, mesmo os produtos do Cripto parece tudo igual, mas são diferentes. Então, a gente fala, e se a gente colocar tais ativos, que são os carros-chefes, num cluster de tópicos com mais partições e ali ter um fine tuning específico para eles, que eu não tenha essa criticidade para outros ativos?

[W] Com certeza. Inclusive, eu acho que a própria B3 e outras empresas que fazem trading, bolsa e etc., os streams deles são diferentes e dedicados pelas ações que eles mais transacionam. Que têm mais volume de mercado, eles conseguem trabalhar de forma separada para que as pequenas ali acabem não atrapalhando e para não ficar um fan-in gigante e ter que ficar fazendo uma separação. Então, eu já sei que ali eu estou lendo só Petrobrás, então, eu sei que eu estou tranquilo em relação a esses tipos de coisa, eu acho que sim.

Agora, deixa eu fazer uma pergunta aqui já baseada no que colocaram. Algumas eu acho que eu, de “orelhudo”, consigo matar, mas vamos lá. Esse fan-in não poderia ser substituído por um sink do Kafka Connect? Minha opinião, eu não faria isso, porque é muito mais barato você criar um microsserviço que só faz um fan-in do que subir um cluster de Kafka Connect para ficar fazendo fan-in apenas de uma coisa. Se tivesse que usar o Kafka Connect extensivamente para vários outros casos, talvez sim valeria a pena, mas fora isso, eu acho que o microsserviço em Go dá mais do que o suficiente para fazer esse fan-in. Ou falei besteira, Rafael?

[R] Faz todo sentido. E, assim, custo é uma coisa que a gente está lidando todo dia. Aqui, a gente está no Confluent Cloud. É caro. É caro, por si só. E aquele papo lá do Rabbit surgiu por causa disso, só o GSRE falou: “velho, você quer colocar tudo no Kafka? Essa conta não vai fechar.” Eu falei, não, eu não quero nada. Só vamos entender as coisas e a gente está até na discussão…

[W] Na realidade vocês foram bem seduzidos para o QC com o DB dá para perceber. Ele ia resolver muita coisa realmente.

[R] Isso. Ele foi uma parte... Antes disso, a gente já tinha entendido o Kafka em testes de... Alguns testes de desempenho que a gente fez, entendendo ali, colocou uns critérios de... O handshake, a troca de mensagem tinha que ser menos do que 10 milissegundos. A gente fez uma listinha de critérios e a gente olhou basicamente para Kafka, o PubSub do GCP, para o próprio NAT Stream, a versão nova dele, o GSTream. Eu não lembro quem era o quarto candidato, mas, dentre eles, a gente foi com Kafka e achou o que fica. Também depois que a gente viu. Mas o lance da Confluent foi a segunda parte da discussão. A gente falou, o Kafka faz sentido. Beleza. A gente não manja nada de Kafka. E agora? Vamos contratar alguém de mercado, porque não faz sentido a gente montar toda a infra aqui agora. Agora, a gente está na parte de discutir. E aí, faz sentido montar a infra dentro? Ainda usar a Confluent, mas fazer do nosso lado, sem ser no cloud deles? A gente está nesses temas porque... E, inclusive, vem as surpresas. Ou mais ou menos, quando a gente vai fazer a diligência de custos de cloud. E todas as suas pegadinhas. A gente tem o Egress Traffic aqui. Por estar usando outro cluster da Confluent. É muito legal estar na Confluent no sentido de que estou no GCP hoje. Eles, não. Estou no GCP. Se você for para a AWS, vou junto para a AWS. Eles fazem um deploy ali, pertinho de você. Mas, ainda assim, é um tráfego de saída. E a gente paga mais por isso também. Então, a gente paga a Confluent, paga o tráfego. Quando a gente começa a colocar todas as coisas na ponta do lápis, fala: “e aí? O que a gente vai fazer?” Então, a gente está o tempo todo olhando para quanto custa esse cluster para tomar alguns próximos passos de decisão.