antes de seguir para a arquitetura Wesley, você está por aí? se estiver por aí, vamos conversar um pouquinho? bora vamos falar aí, cara cara, deixa eu te fazer uma pergunta você que já falou com várias empresas por aí você tem trocado com bastante gente acho que assim, a gente fala bastante os bancos, eles tem uma carga histórica maior, porque eles são empresas mais antigas, né mas, isso acontece em várias você já pegou isso com outras os bancos têm uma carga histórica maior porque são empresas mais antigas. Mas isso acontece em várias. Você já pegou isso com outras empresas na sua empresa, em empresas parceiras, de a gente desenhar arquiteturas que são muito conectadas ou muito desacopladas, ou que não se fala, ou a gente brigar por um stack que é o hypado do momento, mas depois a gente se ferra para contratar ou para resolver problemas desse cara. Você já passou por isso? Cara, demais. Eu vou ser honesto pra você. Eu consigo contar nos dedos todos os projetos que eu comecei dando arquivo novo, novo projeto lá e pra começar. Porque, assim, a gente tem muito sempre aquela vontade de poxa, acabou de lançar aquela tecnologia, acabou de lançar aquilo, eu já quero sair utilizando e de repente eu não posso, eu fico frustrado. E o mais louco de tudo é que eu vejo hoje em dia muitos desenvolvedores que acabam mudando inclusive de empresa porque não querem trabalhar com aquele sistema. E daí o que acontece? Ele muda de empresa porque não querem trabalhar com aquele sistema e daí o que acontece ele muda de empresa ele vai perceber que a história se repete entendeu esse que é o negócio e daí vai mudando e ele acaba esquecendo que a sua senioridade ela não é medida pela linguagem de programação que você está mas sim o tempo que você está. Mas sim, o tempo que você já gastou para resolver problemas. Aquela história. Eu trabalhei 20 anos com PHP, resolvendo um monte de problema. Aí, vamos dizer, eu sou um desenvolvedor sênior. Aí eu vou lá trabalhar, sei lá, no Itaú com o Natan. E os caras lá só usam Kotlin. Então, agora eu sou um júnior? Não, porque o que acontece é que a linguagem, a tecnologia, eu vou ter que me adaptar, obviamente. Obviamente vai ter gente que tem dois anos de experiência só naquela linguagem e vai saber mais do que eu naquela linguagem. Mas o grande ponto é que a experiência que eu acumulei, a sola de sapato que eu gastei, os problemas que eu já sei, coisas que eu sei que funcionam e coisas que eu não sei que funcionam, valem muito mais necessariamente do que a tecnologia que a gente vai usar. Então, eu sinto, e eu já passei por uma fase da minha carreira que tudo que eu queria fazer era mais novo chegava para trabalhar num projeto galera, vamos refazer esse negócio olha, esse negócio está ruim vai dar problema de manutenção mas cara, o projeto tinha três comitês por mês entendeu? então, esse que é o negócio a gente está muito orientado a tecnologia que você falou, mas nunca orientado ao negócio hoje, aqui na Full Cycle, a gente tem um programa que a gente estava olhando agora esses comitês e é um dos nossos sistemas principais o primeiro comitê dele foi meu em 2012 entendeu? E está rodando hoje, e está rodando hoje. E está rodando muito bem. E, obviamente, tem aquelas partes que são tenebrosas, que aos poucos vão trabalhando, mas o sistema nasceu, já acontece no primeiro dia. Então, esses tipos de coisa foi ajudando para que o sistema se mantivesse. E toda vez que alguém chega e fala vamos refazer, eu falo, meu amigo, cara, o negócio está funcionando, entendeu? Só porque você não gosta daquela linguagem ou que esse framework está mais antigo, a gente vai ter que trocar o sistema inteiro, né? Então, eu fico imaginando você aí em bancos que tem um trilhão de sistemas, tem sistemas muito antigos, tem sistemas muito novos, tem arquiteturas de transição. Cara, isso é uma das coisas que eu acho mais importante, e você falou assim, que, na minha opinião, faz todo sentido. Como que eu gero valor entre de onde eu estou e de onde eu quero chegar? Porque não adianta só demorar daqui um ano e entregar um sistema novo, mas do que eu vou entregar durante esse processo. Carlos, consegue falar um pouco mais sobre essa arquitetura de transição? Vou falar. Eu queria até aproveitar para, dentro do que você falou, comentar duas coisas. Eu tenho visto também muita gente, principalmente a galera que está chegando mais nova, como a gente, quando eu estava começando na carreira, a gente tem a expectativa de que, se eu estiver rodando na linguagem mais nova, eu sou o cara mais ferrado. E eu estou com você, tá? Várias vezes a gente precisa das pessoas entendendo e conseguindo ser resilientes para o que elas têm para fazer no dia a dia. Vai ter mudança de tecnologia, você vai começar uma tecnologia e vai dar dois anos e ela já não vai ser a mais nova, então isso vai acontecer as mudanças elas vão acontecer é mais sobre como você consegue lidar em ambientes complexos isso vai te dar uma bagagem gigantesca do que sobre uma tecnologia específica acho que as tecnologias a gente vai se adaptando não tem jeito, a gente vai ter que se adaptar cada vez mais, talvez quando eu comecei minha carreira, a gente tinha menos linguagens nascendo, hoje eu durmo quando acordo tem uma linguagem nova, tem um negócio novo chegando, então eu acho que a gente tem que se provocar pra, quanto que eu tenho de história, acho que é em cima do legado ali, tá? Quanto que eu já gerei de legado, que isso vai te dar bagagem, peito para você chegar e falar, puta, pode vir qualquer linguagem aqui que eu vou para cima. E, sinceramente, a maior parte das grandes empresas, elas vão ter uma bagagem aí de sistemas cruzados que vão estar em várias linguagens diferentes, em vários momentos diferentes, e você vai passar por isso na sua vida. Então, é legal você ter essa troca. E lembrar do seguinte, a gente dá pouco valor por quem já viveu. A galera que já fez isso, que já tá há anos no mercado conhece pra caramba, é muito importante você ter um cara desse do seu lado pra perguntar, pra falar, mas como é que você passou por isso, como é que você resolveu aquilo o que eu já entrei Wesley, em troubleshooting de falar, puta, o cara manja pra caramba tecnicamente não sabe fazer um troubleshooting, não sabe como separar os assuntos pra tomar uma linha de ação. Enquanto quem é mais antigão de sistema, já mexeu 500 vezes, o cara separa ali na hora, fatia e fala pra cá que eu vou, vou tentar resolver desse jeito. Não, vou tentar liberar o sistema dessa outra maneira. A galera tem muito a ensinar. Então eu acho bem importante a gente ter isso. Sobre arquitetura de transição, eu acho bem importante a gente ter isso. Sobre arquitetura de transição, eu acho que a gente tem alguns pontos aqui. A primeira coisa, eu gosto de definir uma arquitetura-alvo para a gente saber onde a gente quer chegar, mas é uma provocação que eu faço sempre para o meu time. Alguma vez a gente chegou em uma arquitetura-alvo? Porque a gente define uma arquitetura-alvo que é a arquitet de tecnologia a gente vai refinar a arquitetura, vai colocar mais uma coisinha, outra coisinha, outra coisinha antigamente a gente desenhava sistemas pra terminar entregar e acabou hoje em dia a gente não termina, o sistema não termina quando você termina, você volta pra resolver um débito técnico, pra mudar uma coisinha que você imaginou diferente pra trazer mais velocidade, mais resiliência, mais não sei o que. Então, conforme você vai montando, entregando as arquiteturas de transição, você vai tendo ideias e sacadas que podem melhorar ainda mais a sua arquitetura alvo. Então, a arquitetura alvo, eu costumo brincar que ela é utópica. Você não vai chegar nela. Se você chegar nela, uma hora o seu sistema vai ser legado. Então, você sempre tem que ir subindo a barra. Você cria ela agora, pra daqui um ano, pra todo mundo saber daqui um, dois anos, pô, é aqui que eu quero chegar. Mas no meio do caminho, ela vai se modificando. Se ela ficar estagnada, você vai deixar seu sistema pra trás também. Lógico que cada vez você vai estar mais perto da arquitetura algo, mas você é muito difícil de você falar, puta, terminou o sistema, agora não mexo mais. Então, as arquiteturas de transição, eu gosto de fazer coisas do tipo, eu vou dar alguns exemplos. Eu tive que fazer um projeto onde eu estava pegando uma plataforma inteira, tirando uma Azure, trazendo para uma AWS e esse sistema, ele tinha várias integrações ali, ele era bem antigo sendo bem honesto, ele não estava muito bem feito ele não estava com testes da melhor forma pouca resiliência, um monte de coisas que dava pra gente resolver a zero de jogo, o que eu pensei foi putz, eu preciso trazer esse cara ele estava nos Estados Unidos, ele rodava mais perto da sua casa do que da minha aqui em São Paulo a gente precisava trazer ele para cá, porque era mais fácil de lidar com ele aqui, a gente ia ter tempo de resposta melhor. Tudo bem que eu podia usar a cloud font, beleza, mas era mais fácil trazer ele para cá para a gente lidar com ele mais perto dos nossos clientes. E a gente tinha que pensar em algumas coisas de dados, porque não estava tão bem feita a modelagem de dados, etc. O que a gente fez no primeiro momento foi, vamos criar uma Kafka, deixa ele rodando nos Estados Unidos, e eu vou trazer para cá só o front-end, front-end BFF. Vou fazer o front-end BFF aqui. O que isso vai trazer de benefício? Putz, se eu só trouxer o front-end BFF para cá e deixar ele igual que tinha lá, para o meu cliente não mudou nada, e deixar ele igual que tinha lá, para o meu cliente não mudou nada. Ele só tem mais tempo de latência se bobear. Então, a gente pensou na latência de rede, a gente pensou em como isso impactar o cliente e fez um teste. O cliente fez um lab falando, cara, o que te traz valor? E a gente viu que algumas mudanças de front bem simples poderiam trazer valor. Então, na primeira entrega, a gente fez o seguinte, entrega umas mudanças de front simples, entrega um BFF aqui. Puta, já fizemos uma primeira mudança, já entregamos e o cliente já achou legal. Então, já começou a mexer no nosso índice de satisfação do cliente com essa primeira entrega. Os stakeholders acharam bacana, a gente teve esse caso que eu te falei, era esse caso da consulta de saldo, mas a gente não tinha trazido ela, ela ainda estava com tempo de demora, na verdade piorou era, sei lá, 14, ficou 15 segundos a gente falou, não, tudo bem está ruim, mas já, pelo menos a experiência para o cliente do front já melhorou vamos para o próximo passo, quais são as APIs que ficaram piores uma delas era o contexto de saldo vamos trazer escala primeiro, então? vamos, trouxemos, ficou bem mais rápido. Tá, beleza. Então vamos trazer extrato? Vamos. Então a gente começou a falar, olha, as arquiteturas de transição, primeiro eu tinha um front com BFF aqui que batia lá na conta antiga. Tudo bem, esses caras já estavam bem. Mas eu coloquei um BFF justamente para tirar o acoplamento com front e para deixar esse cara já preparado para fazer um chaveamento para quando eu trouxesse uma API para cá. Essa foi a minha crise de transição simples, mas foi a primeira que a gente fez. O segundo passo foi, traz as APIs principais para cá, com os contextos que a gente definiu, e começa a chavear para elas. O banco de dados, deixa lá, não tem problema. Deixa ele lá. E a gente continua apontando o banco de dados lá. O que a gente fez? Para a gente diminuir latência, a gente começou a cachear. Deixa eu usar cache aqui no primeiro momento. Ah, é a melhor das experiências? Não, não é. A gente precisava, por exemplo, consulta de saldo, ela é muito dinâmica, não é legal você estar usando cache a todo momento. Então a gente falou, vamos cachear no primeiro momento até a gente tombar o dado para jeito que está e depois a gente muda a morfologia dele para cá, então uma outra coisa que foi muito importante foi esse tempo todo eu tive muita parceria com a galera de negócio com a galera que pensa muito no business ali da gente definir coisas que a gente ia fazer para daqui um mês jogar no lixo eu vou fazer isso aqui e eu vou jogar no lixo está claro que a gente vai jogar no lixo aí eu vou fazer com observabilidade? Vou vai ser a melhor do mundo? Não, vai ser a pra sobreviver durante dois meses, na próxima que a gente entregar é com a melhor do mundo isso ficou muito claro porque também a gente tinha um time muito maduro de liderança em cima do assunto pra chegar e falar assim, olha, tudo bem, a gente entende que a gente tá entregando uma vou te dar um exemplo, a gente tá entregando observabilidade com painéis e com alertas mínimos. Mas daqui dois meses a gente vai entregar uma parruda. E depois de dois meses a gente entregou. Uma outra coisa que a gente faz muito mal é, depois que a gente viu o benefício, a gente para de evoluir aquele assunto. E o que a gente fez muito bem foi de definir, deixar muito claro, a gente deu as mãos e falou o seguinte, a gente vai entregar, vai jogar no lixo e vai fazer melhor daqui dois