Acho que para a arquitetura é sempre bom a gente lembrar alguns conceitos que a gente não pode esquecer. A gente tem que pensar em desacoplamento da arquitetura. Facilmente a gente constrói contextos que se conectam, eles vão se conectar porque normalmente um negócio precisa de várias peças para sobreviver, mas criar desacoplamento é extremamente importante. E uma coisa que eu estava falando agora ali com o Wesley, que acho que é legal a gente pensar, a gente fala muito do desacoplamento, para quem já faz sistema há bastante tempo, a gente fala muito do desacoplamento na hora de usar a plataforma ou na hora de ter que fazer uma mudança. Sei lá, chegou um projeto novo, a peça que eu estou mexendo não pode estar acoplada com a peça da minha squad do lado, com o contexto do lado, etc. Mas é bom você pensar também em desacoplamento em ambientes de teste, tá? Às vezes a gente cria tudo bem desacoplado numa visão de arquitetura, mas a gente cria um acoplamento na hora de testar, o que é bem complicado, tá? Porque depois no dia a dia você vai ter contextos diferentes, com equipes diferentes, prioridades diferentes, pode acontecer. Não acontece nunca, mas toda hora está acontecendo. E daí as coisas não vão se falar, você vai depender de uma da outra para ter o time de marketing, para conseguir lançar coisas novas. Então é bacana você sempre pensar na forma de deixar tudo o mais desacoplado possível. E aqui também um outro ponto, o quanto que o seu acoplamento pode gerar de impacto no ambiente todo. Quando você tem vários times para fazer um sistema gigante, as matérias de Circuit Breaker, de pensar em como que a minha aplicação, ela não vai roubar todas as demais, de pensar em como que eu posso usar um bookhead, de uma ideia de como que eu impacto, mas impacto menor o problema todo, ou deixo a minha aplicação mais setorizada em várias máquinas pra gente não derrubar tudo, diminuir carga quando necessário. Quando você tá falando de um sistema extremamente complexo com várias interligações, por mais que você deixe os microserviços autocontidos, você tem que pensar em como que o seu microserviço autocontido pode ir de impacto para o outro. Vou dar um exemplo. Cara, vou lá e vou fazer um microserviço de recebimento de pagamento via Pix. Ou de compra. Vamos fazer um marketplace para não falar só de banco. Puts, estou lá fazendo um serviço de marketplace. Puts, vou fazer um recebimento de vários pedidos de compra. Chegou o momento e engargalou. Os caras estão fazendo um monte de pedido e eu preciso processar o pagamento no meu contexto de pagamento aqui dentro de casa. Beleza, você recebeu vários pedidos e você fala, putz, eu estou com o sistema de pagamento fora e eu vou represar esses caras aqui para depois processar e depois mandar uma lista de e-mail para todo mundo falando, ó, ou um SMS ou o Whats, falando, cara, o seu pagamento foi aceito e o seu pedido vai chegar. Beleza, simples. Então tem um cara aqui, uma peça que vai fazer o pedido, tem uma peça de pagamento e tem uma mensageria que vai devolver falando, ó, deu certo ou não deu certo quando isso cai. Então, a zero de jogo, a sua resposta vai ser síncrona, por mais que você pense, você pode até pensar no sistema síncrono, mas você vai responder no mesmo momento pro front-end, pro aplicativo. Recebeu pedido, pagamento tá de pé, recebeu pagamento, toma, deu tudo certo. O pagamento caiu, recebeu pedido, pagamento caiu, respondo na tela, cara, aguarda um pouquinho que daqui a pouco no seu e-mail você vai receber a confirmação. Bacana, fui represando aqui, represei, represei, represei. Na hora que voltou o sistema de pagamento, possivelmente, esse cara de pagamento, ele se preparou para receber uma rajada, porque você segurou um monte de coisa ali, ou pode ser que ele tenha segurado o lado dele. ou um monte de coisa ali. Ou pode ser que ele tenha segurado o lado dele. Primeiro, essa conversa tem que ser extremamente alinhada para você também não segurar os processamentos aqui. Ele segurar lá parece besteira, mas é bom vocês fecharem essa perna. Puta, quem que vai segurar aqui a requisição para fazer os processamentos? Vai ser o time ali de pagamentos? Beleza. Quando você lê que tudo isso começou a sair para conseguir mandar de volta o e-mail ou o WhatsApp ou etc mensageria para o cliente, essa peça que você pensou aqui, que pode ter sido outra pessoa do seu time ou outro time que é só de mensageria, ele está preparado para receber uma porrada de requisição? Às vezes ele estava preparado, ele fez um serviço de mensageria ali para atender um exemplo, para atender compras pequenas ali, sei lá, um marketplace que está vendendo bens ali, eu estou vendendo máquinas de lavar, estou vendendo bens de consumo, beleza. Ah, mas estou tendo uma campanha agora que eu estou vendendo ingresso e estou usando esse mesmo sistema, ingresso para o Detal, estou vendendo ingresso para o Lollapalooza. Vai vir uma rajada de requisição e essa mensageria vai aguentar mandar depois ou ela vai capotar? É legal pensar em como essas coisas se falam para dentro do desacoplamento você também pensar em como os sistemas desacoplados vão ter resiliência. Eu vou falar de resiliência, tá? Eu vou falar de resiliência abaixo, mas é interessante a gente pensar no desacoplamento pra pensar na resiliência ao mesmo tempo quando você tá gerando contextos muito separados. Pensar também que o desacoplamento, quando a gente fala disso também, não gerar gargalo. Se você tiver contextos que não são autocontíduos, que não conseguem se resolver, não tem autonomia, possivelmente no dia a dia você vai ter esses pedidos cruzados. Olha, eu preciso fazer isso, mas eu preciso desse outro time que também faz, que precisa desse outro time que também faz. E para fazer qualquer coisinha pequena, você está gerando times que não tem autonomia e deve virar um gargalo, porque os contextos estão se cruzando, cada um quer fazer uma coisa e todo mundo se odiando ali no dia a dia, porque ninguém consegue cuidado com uma lei também que tem que é a lei de Conway o quanto que a gente está pegando o nosso sistema e copiando o que tem na nossa organização ou seja, putz, tem o time do Wesley que está aqui com um contexto, o time do Nathan está com outro contexto então vamos separar, porque o time do Wesley e o time do Nathan não, vamos separar os contextos invariavelmente vai acontecer de você copiar a sua topologia de empresa o seu sistema ele tem algum impacto dado a topologia, isso é normal é uma lei que pega mesmo no dia a dia, vai acontecer mas como você faz para diminuir ao máximo isso e não ficar enviesado pelos nomes das cadeiras e não pelos contextos do seu domínio de negócio Resiliência. Acho que a gente tem que pensar bastante nisso quando a gente está falando de uma arquitetura para fazer uma mudança desse tamanho. É você abusar de perguntar, mas e se? Sei lá, e se o sistema de pagamento cair? E se o sistema de ingresso, de compra de ingresso cair? E se o sistema de tracking, de mercadoria cair? O que vai acontecer? E se aumentar o número de requisições? Se cair o número de requisições? Baixou muito, ficou quase zero. O que acontece? Será que eu preciso de um alerta porque pode ter alguma coisa fora? Sei lá, eu tinha mil requisições por hora e agora está tendo zero? Tem alguma coisa esquisita aqui. Então aqui. Então, pensar nos e se. Sempre pensar nisso. Para a sua resiliência da sua aplicação. A gente costuma não fazer isso, tá? No dia a dia, a gente pensa muito no caminho de como as coisas funcionam e a gente pensa pouco no como elas vão acontecer se não funcionar. Se tudo der errado, o que vai acontecer? Aprende com quem já fez. Se tem um sistema lá, possivelmente ele já passou por poucas e boas. Quando você implementa um sistema, você começa a aprender. Isso a gente esquece também. Um sistema de 50 anos, ele tem 50 anos de história, de aprendizado, de código novo sendo colocado, de ideias diferentes, de pessoas que passaram e aperfeiçoaram esse cargo. Putz, ele está na melhor linguagem? Pode esse cargo. Putz, ele está na melhor linguagem? Pode não estar, ele pode estar acoplado, pode ter um monte de coisa, mas ele já passou por muito conhecimento. Entenda com quem já passou por isso, entenda com o sistema que você já tem, para você ter a melhor conversa, você ter a melhor informação para tomadas de decisão ali, para montar uma resiliência. Outra coisa, você vai precisar ter conversas duras sobre as prioridades e sobre o que eu conversei aqui com o Wesley, de, putz, isso aqui eu vou ter que construir, depois eu vou ter que jogar fora, mas eu vou ter que fazer isso do jeito certo daqui uma semana. A gente vai construir para entregar, ficar uma semana testando, jogar fora e fazer. Às vezes você vai precisar disso. E para fazer isso, é muito importante você ter claro, ter claro o que você vai entregar e qual vai ser a prioridade disso e, para a resiliência, você pensar em qual a prioridade de execução de cada coisa. Eu até criei uma lei, porque eu nunca vou ter uma lei no meu nome porque eu não sou nenhum gênio da matemática ou da física, mas eu criei uma lei no meu nome, a Lei dos Freitas. Coloquei até o meu nome em português, que é para dar bastante peso de autoridade aqui. Você tem que tratar o seu sistema como se fosse um corpo humano. Você tem que definir as prioridades das funções ali. Sabe por quê? Ah, é importante a gente ter a nossa visão? É importante. É importante a gente ter A nossa visão É importante É importante a gente ter, sei lá O nosso movimento do braço É importante, mas é mais importante o nosso coração bater É mais importante a gente ter um cérebro que está funcionando Então quando a gente tem algum problema A gente vai atacar primeiro os sistemas centrais E deixar eles funcionando Seu sistema tem que ser a mesma coisa É importante eu ter um meio de venda Por exemplo, de ticket do Lollapalooza no meu app? Puta, é importante. É importante eu ter esse mesmo cara conseguindo ser vendido por uma agência no shopping? Sei lá, uma loja no shopping? É importante. Se começar a estar um problema, quem que eu derrubo? Derrubo a loja ou derrubo o sistema online? Derrubo o meu app. Eu tenho que tomar essa decisão. Se eu tiver muito problema acontecendo no core do sistema, o que eu toco perder? O que eu perco primeiro antes de sair derrubando tudo? Acho que é importante ter essas conversas duras e pensar que o nosso sistema é assim como se fosse um sistema vivo, um sistema do corpo humano. Você tem que definir prioridades e aceitar perder algumas em determinado momento. Dificilmente quando você for falar com alguém, com o cliente, com alguém, o seu stakeholder ou alguém de produto, dificilmente a gente entende isso como uma coisa boa, mas no dia a dia é bom, porque quando tem problema, você sabe aonde você vai perder primeiro e já constrói seu sistema com a resiliência orientada a isso.