O que deu errado dessa história toda? Quando a gente foi colocar no ar, desenhou tudo muito bacana, vários testes, testes de carga, testes de tudo o que a gente conseguiu fazer. O que a gente teve de surpresa? O KSQLdb, que era o que a gente não esperava. Talvez o que a gente até teve de surpresa, porque talvez tenha confiado demais que ele já ia resolver todos os problemas do nosso universo ali, a certa medida. 

Mas assim que nós subimos, a gente fechou com a Confluent para poder usar a solução deles. A gente está usando a Kafka pela primeira vez, não somos especialistas, vamos trazer alguém que ajude a gente. E bateu no limite de que só podia ter 10 query tables no KSQLdb, nosso cluster. E a gente ficou muito encucado com isso, porque a gente subiu, a primeira versão daqui tinha literalmente 10 microsserviços, porque eram dois fluxos, cinco em cada, e cinco passos em cada ali nos microsserviços, cada microsserviço tem três tópicos. A gente fez no primeiro desenho cada tópico vira uma table view, porque eu quero olhar cada um desses caras.

Como são? Era o pensamento lógico quando a gente estudou o desenho. E aí temos um problema legal. A gente já começa com 30 e o limite é 10. A gente abriu o chamado na Confluent. Eles mudaram para 100. E a gente ficou muito intrigado com isso. Chamou os caras para conversar. Por que 10? O que está acontecendo? A parte engraçada de falar com o pessoal. O pessoal do comercial: “Pow, você tem um hard limit aí”.  O cara: “não, não é hard, você abriu um chamado, eu mudei, então não é hard, é soft limit”. Mas você tem um soft limit que, assim, não condiz com o que eu desenhei, e eu tinha de mostrar o que eu desenhei, então assim, o que está acontecendo? Por que tem esses números? Basicamente, entra naquela coisa de recurso computacional, tudo mais, nenhuma resposta concreta do porquê. A gente fez testes, a gente não foi totalmente leviando isso aqui, a gente fez testes, a gente fez testes de carga metendo duas mil table views numa imagem Docker da Confluent do KSQLdb no nosso ambiente, mas dentro do ecossistema deles, totalmente deles, estavam as  questões das limitações. E a gente ficou muito intrigado. 

Mas e  como aumenta isso? Não aumenta? O que vocês recomendam? Falei: “não, você tem esse limite de até 100 por cluster. Você pode criar mais de um cluster Kafka”. Falei: “legal”. “E você pode criar no máximo 10 clusters”. Falei: “ok”. Então, assim, você continua não me ajudando muito, porque… e a gente ficou muito encucado com a parte de, a Confluent é referência no kafka. E eles colocaram um limite nesse troço. Devem ter algum motivo que a gente ainda não está enxergando. 

E a gente falou: “vamos mudar a estratégia!” O que a gente faz? Então, para contornar isso, foi lá e criou um Fan- In, que era um microsserviço que ouve todos os tópicos que tem antes. E só o que ele fazia é: pega a mensagem de um tópico e escreve em um outro tópico, em três tópicos, o GSM1, GSM Compensate e GSM-error. Porque daí a gente criou só três table views. No KSQLdb, contornamos todas as... Foi uma situação bem gambiarra, para a gente contornar a limitação que a gente estava, mas legal. Vamos seguir com as fases de rollout aqui, o deploy, colocar mais usuários na solução para ir vendo como vai se comportar. 

A rasteira número dois foi que esse cara não... Ele começou a degradar. Ele começou a fazer consultas. E a gente foi entender melhor que para o tipo de consulta que a gente quer fazer, ele não é o banco para isso. Ele é muito bom pra colar ali, ou sei lá, algum tipo de relatório, umas coisas bem específicas, mas não o específico que a gente precisa. Que a gente quer fazer perguntas desse tipo aqui; me dá tudo que está com erro em tal passo. Ou, me dá o estado, e esse era o pior, me dá o estado dessa transação. Vai jogar um ID lá e ele, porque como estavam as views, ele começava a se perder de algum grau ali para organizar as coisas, para achar esse parâmetro. Pelo ID, não tinha uma chave. Então, era uma chave para a gente, mas não para ele, na estrutura dele. Então, a gente falou, cara, não vai dar bom. 

A gente voltou a redescutir com a SRE. Ideias de se a base de dados é o que a gente realmente quer, para onde a gente vai, se isso tem que estar no cluster da Confluent ou no nosso cluster, a gestão desses dados mesmo, porque aqui é que está nossa mina de ouro, são os dados transacionais para auditoria futura, para entender o que aconteceu com uma transação, qualquer coisa que a gente queira fazer. E o principal motivador para o KSQL foi o fato de a gente não precisar criar um microsserviço para ouvir tudo, e foi o que a gente fez.