Meus calos para desenvolver um serviço de controle de saldo

Nesta sprint minha tarefa e maior dificuldade foi trabalhar em cima de uma estratégia para conseguir fazer um sistema de controle de saldo financeiro que fosse extremamente confiável e ao mesmo tempo suportasse uma carga de requisições muito alta para o mesmo registro e que conseguisse dar conta de atender a todas as requisições sem ter inconsistência nos valores, pois se tratando de um sistema financeiro considero que é algo inaceitável. Nesta jornada tive muitas dificuldades para pensar em soluções e por consequência disto obtive muitos aprendizados que com certeza farão a diferença no futuro.

Entendendo os serviços

Minha primeira dificuldade foi entender toda a estrutura que o sistema faria parte e como iria integrar com os demais serviços, por mais que já tinha o conhecimento de toda a arquitetura e o desenvolvimento dos serviços não tinha um conhecimento aprofundado no fluxo que se desenvolve dentro de cada serviço e da aplicação como um todo para que conseguisse iniciar ao menos um esboço do que poderia ser desenvolvido e utilizado para concluir a tarefa. Após conseguir entender conseguir entender os fluxos que se desenvolvia no sistema foi possível avançar uma etapa e começar a pensar em como poderia ser desenvolvido e implementar uma versão para validar, o que me mostrou alguns problemas que tenho e me trouxe algumas coisas que precisava enxergar para crescer.

Soluções e implementações

Neste momento era necessário entender como lidar com o alto fluxo de requisições no sistema como um todo e principalmente na peculiaridade do sistema que é a alta demanda de requisições para o mesmo registo de saldo. Eu segui uma abordagem que utilizaria uma variável dentro do registo para fazer um controle de versão dos dados, muito desta decisão veio de estar pensando em tentar uma implementação com o MongoDB, que parcialmente resolvia meu problema, porém atropelando os bois com o carro eu quis logo ir testar a possível solução sem ainda enter muito bem os requisitos e como a ferramenta funciona, e com isso veio a primeira falha.

Nesta implementação sempre que eu estava fazendo uma alteração nos registros eu tinha que fazer uma busca, atualizar e na hora de salvar precisa fazer a busca pelo identificar e a versão do registro, até este ponto ok, solução valida, os dados atualizando corretamente e tudo perfeito, o problema veio quando fui testar com um volume maior de requisições e agora começou os problemas por não parar para analisar com calma as informações que tinha. E meu primeiro problema claramente foi de enquanto uma requisição atualizava os valores outra já tinha atualizado e alterado a versão dos dados o que levou ao erro de não existir o registro e mesmo tendo previsto isso e já prever que seria necessário uma solução de múltiplas tentativas o problema ficou maior quando vi que sempre estava extrapolando a quantidade de tentativas máxima definida e aqui eu comecei a perceber a casa caindo e pra tentar segurar fui atrás de entender um pouco mais do funcionamento do Mongo na tentativa de achar uma configuração que pudesse fazer ou um recurso que não conhecia para utilizar.

Já era de conhecimento que o Mongo suporta transações ACID, porém não havia implementado então fui eu fazer as modificações no código para que tenha as atualizações acontecendo de forma única o que eliminaria a utilização da versão dos dados e quem sabe as diversas tentativas de atualizar o mesmo registro, porém como de se esperar não tive sucesso, desta vez comecei a ter erros da própria engine do mongo sobre não estar suportando a quantidade de tentativas, e neste ponto já não sabia se o problema estava na solução que desenhei ou nas ferramentas utilizadas.

Quando minhas tentativas ruíram eu fui atrás de ajuda ainda insistindo no mongo, com ajuda fui direcionado a tentar fazer utilizando o Postgres, algo que já tinha pensado, más talvez por influência de posts sobre discussões sobre o que usar e sabendo que nenhum tecnologia é bala de prata ainda seguia na cabeça que por não ser algo que seria necessário relacionamento entre tabelas não faria muito sentido usar o PG. Após conversas de ajuda segui a mesma abordagem de controle porém substituindo o Mongo pelo PG e de novo não atendeu as minhas expectativas. Neste ponto eu fui atrás de lideranças para expor que estava com dificuldades e talvez trocar de tarefa pra ver se tinha uma virada de chave para que conseguisse concluir a tarefa no futuro, e fui designado para outras tarefas que não acho que valha ser mencionadas.

A liderança pegou as coisas que fiz que não funcionavam e com alguns ajustes fez funcionar e veio me reportar as alterações e o funcionamento da solução, fiquei bem feliz pois apesar de não ter sido eu que fiz funcionar era uma solução proposta por mim então no tempo que tive corri para ver as mudanças e absorver o que foi alterado para que conseguisse aprender sobre e neste ponto é onde veio talvez o maior aprendizado que tive durante a sprint que foi buscar ajuda quando tem dificuldade antes de terminar o prazo e apesar de as vezes já fazer essa troca de tarefa para se desligar de um problema eu sempre ficar com ele na cabeça tentando resolver e na maioria das vezes não vem a resposta né. E outro grande aprendizado veio sobre explorar mais as ferramentas que utiliza, que apesar de ter feito isto com o Mongo no PG eu não fiz e a solução do problema partiu disto, pois com algumas mudanças de configurações, aumento de limites e recursos de busca e de transações foi possível resolver o problema.

E pra finalizar outra boa lição foi o uso de IA, neste processo utilizei muito IA para tentar chegar a uma implementação que funcionasse e do que foi feito a maior parte eu tive que desenvolver na mão com IA ajudando muito pouco então pra mim que estava tentando delegar certas coisas pra IA e tentando evitar o trabalho de pensar em soluções eu percebi que não é bem assim que a banda toca.

Se você chegou até aqui meu muito obrigado por estar lendo.