Fernando, vamos lá mas quiser mandar as perguntas porque até me sinaliza se eu estou indo bem ou estou indo mal beleza? tá um dos pontos aqui é qual caso você acredita que não não vale a pena ou que não é possível utilizar balanceamento de carga horizontal boa, mantenha-se aqui que a gente vai continuar nisso tá joia a gente vai responder no conteúdo espero que seja hoje, que já chegamos a 30, 40 minutos. Mas a pergunta é ótima, beleza? Na verdade, há uma outra estratégia, não sei quem perguntou aí, mas há uma outra estratégia que é o seguinte. Cara, será que eu consigo aplicar isso em todos os cenários? Tem um cenário que é difícil aplicar escalonamento horizontal. E aí a gente muda o software incluso para a gente provocar o escalonamento horizontal. Fernando, há cenários onde eu não consigo promover aqui? Com certeza. Tem cenários que a gente precisa manter que vai estar na máquina. E aí eu não consigo escalar. Mas eu vou falar disso já já, beleza? Mas a pergunta foi ótima, eu gostei da pergunta aí. Fernando, mas todos, acho que tem algo aqui para mim que começa a vir. Todas as operações eu consigo, e talvez aí a pessoa que perguntou isso aí, talvez vai estar alinhado ao que ela falou aí. Fernando, todas as operações que eu faço, eu consigo gerar esse scale de forma igual? Vamos imaginar um cenário com o Ed, comigo, beleza? Eu tenho um serviço de upload de imagens, pode ser? Perfeito. Todo mundo consegue imaginar um serviço de upload de imagens, pode ser? Perfeito. Todo mundo consegue imaginar um serviço de upload de imagens? Tranquilo, né? Tranquilo. Todo mundo já fez isso aí na vida, né? Já subiu uma imagem em algum lugar. Posso pagar aqui, né? Pode. Então, num case A, onde eu tenho um onde eu vou fazer o upload de imagem, você pode me indicar o que é comum, Wesley, num upload de imagem? O que é comum num sistema de upload de imagem? O que é comum num sistema de upload de imagem? Imagem, é. Você é meu brother. Tá. Bom, eu tenho que ter um local para eu armazenar as imagens. Eu preciso de um storage, que isso aí vai ser comum, que eu vou precisar. Está disponível. Beleza. Boa. Outra coisa que eu vou... Em qual aspecto que você quer que fale? O que eu preciso ter num sistema de imagens, só para eu entender? Boa, boa. Se fica a dica aqui para todo mundo, talvez essa seja a primeira lição antes da gente falar de RPO e RPO, Wesley. Foi isso que você acabou de fazer. Quando a gente vai falar com o usuário e a gente tem um requisito para fazer um design system, a gente precisa alinhar as expectativas de requisito. Então, a gente trazer à toa nas nossas dúvidas é o mais relevante, por mais simples que elas sejam. Num sistema de imagem, o que a gente tem que talvez me preocuparia? Primeiro, eu vou ter muita gente subindo imagens, fazendo upload de imagens de carga, de tamanhos diferentes, concorda comigo? Eu vou subir imagens e essas minhas imagens podem ter tamanhos irrisórios e tamanhos gigantescos, concorda? E às vezes os sistemas de imagem, Wesley, eles até bloqueiam, né? Quando passa de uma certa quantidade de bytes, esse cara vai lá e ele me bloqueia. Concorda comigo? Perfeito. Eles me bloqueiam. Então, por quê? Porque faz também parte do System Design. Então eu posso também, esse meu upload, ele pode ser comprometido, né? O meu upload pode ser comprometido por conta desse meu request, que ele pode ser longo, concorda? Perfeitamente. Então, eu vou ter um comportamento de request que eu desconheço aqui, cara. Baseado no tamanho da minha imagem, se meu request pode ser longuíssimo. Certo? E esse meu sistema de upload, também normalmente quando eu subo essa minha imagem, ele me retorna, a gente vê a maior parte do sistema, o Instagram, quando eu faço upload na minha imagem, esse cara me retorna uma representação dessa imagem, que a gente chama de thumbnail, não era isso? É thumbnail mesmo. É thumbnail mesmo. Faz tempo que não faço tema de upload de imagem, mas era isso que a gente chamava, né? De thumbnail. Então, essa representação dessa imagem, essa representação dessa imagem, essa representação menor dessa imagem, ela também vai trazer para mim, pode ser que essa quantidade de request, como na verdade eu vou trazer essa imagem, esse request também vai ser menor. Então, eu vou ter dois cenários aí. Então, eu vou ter dois cenários aí. Então, eu vou ter tipos de requests distintos dentro de um mesmo servidor. Num case A, se eu fosse tratar uma upload de imagem, eu teria que imaginar que eu vou ter tipos de requests distintos para a mesma infraestrutura. Então, naquele desenho que eu estava tratando, uma problemática num escalonamento padronizado é eu tratar todos os sequestros de forma igual. E aí o que acaba acontecendo é eu ter o escalonamento ou o desenho do System Design comprometido porque está todo mundo fazendo a mesma responsabilidade. O que a gente faz normalmente também quando a gente quer evitar o problema do N mais 1 de forma ou N mais 2 de forma incorreta é separar as responsabilidades. Então, Fernando, mas isso vai trazer um custo. É, isso traz um custo inicial, mas o que acaba acontecendo é que quando eu quero fazer o meu escalamento horizontal, eu acabo sendo mais, vou chamar aqui caso de B', pode ser, gente? B2, e vou chamar aqui caso de B linha, pode ser gente? B2 e vou chamar aqui case B eu vou separar aqui, mas vou deixar case B para ficar melhor, para fazer sentido case B o que normalmente a gente sugere? Cara, primeira lição da arquitetura de software, dividir as responsabilidades, mantenha-se simples, vamos fazer simples, vamos com o cenário B, o que eu teria? A gente teria dois servidores, onde eu teria o seguinte, um servidor tratando os processamentos de longa duração, vou chamar aqui os sequestes de longa duração, certo? Por exemplo, subir imagens e os sequestros de baixa duração que seriam os thumbnails em outra. Pernambuco, muitos servidores de upload na internet fazem isso? Muitos provedores de serviço fazem isso. Eles acabam separando por quê? Porque existe uma máxima. A rede não se escalona. Tudo se escalona em computação, Wesley, menos rede. Então, é uma problemática. Por quê? Porque quando eu quero fazer o que me complica o meu scale horizontalizado, às vezes, em alguns cenários, é que para eu responder, às vezes, dentro de um pool de nó, mantendo aquele comportamento, ou recebendo um comportamento diferente dentro do mesmo nó, eu tenho que escalar a máquina de forma incorreta. Então, quando a gente fala de réplica, quando a gente traz o tema das replicações de servidores na mesa, isso é um problema. Por que isso é um problema? Se eu não divido os meus componentes de forma, se eu não entendo os componentes que fazem parte do meu design de forma a poder dividir para manter a réplica mais satisfatória, o que vai acabar acontecendo é que de forma não saudável, se eu posso chamar assim, eu vou estar replicando recursos de forma incorreta. Então, nesse cenário aqui, no case A, o que acabaria acontecendo? Se eu fosse replicar esse cenário por conta de requests de longa duração, possivelmente o shape dessa minha máquina aqui, ele seria comprometido, ele seria um shape maior do que requests de baixa duração. E aí o que acabaria acontecendo é que eu teria que dentro de um load pool, não sei se esse termo é comum para todo mundo, mas dentro de um load pool de servidores, o que acabaria acontecendo é que eu teria um scale incorreto, um scale horizontal de forma incorreta. Então, para que a réplica seja uma réplica válida, eu preciso entender no detalhe também as responsabilidades das peças dos meus softwares ou das peças do workload que eu preciso responder. Então, esse é um exemplo muito bobo, muito simples, onde eu tenho um upload de imagem, mas que num caso crítico, onde eu tenha muita gente compartilhando request e fazendo consulta de servidores, eu vou ter possivelmente servidores com menor representação de request, com poucos queries por segundo, versus servidores com baixas queries por segundo. Então, você imagina, um servidor de upload, possivelmente eu vou ter baixas queries por segundo. Fernando, não faz sentido. Eu subo imagem toda hora no meu Instagram. Vamos fazer o seguinte. Você está para dormir, Wesley. Aí você pega o seu celular. Aí você deita lá no sofá da sua cama, lá no seu quarto, na sua sala, aí você está zapeando o Instagram. Minha pergunta, você mais zapeia o Instagram ou você mais usa upload de imagem? Pois é, a leitura é muito maior, não tem nem como... Ah, a leitura é muito maior. Então, a quantidade de query por segundo que eu faço para a minha operação de escrita e leitura são diferentes, concorda? Exatamente isso. Provavelmente a proporção é muito diferente aí, né? Exatamente. Obrigado. Então, num cenário aqui, onde vamos chamar aqui, tá? Eu vou deixar a setinha para baixo escrita e setinha pra cima leitura. Pode ser só pra gente simplificar o exemplo? Então, aqui, opa. Então, aqui, ó, a quantidade de escrita que eu vou ter aqui, cara, ela é incompatível. Então, alguém perguntou aí, cara, aonde não faz sentido, né? Bem, já não faria sentido se eu tivesse um cenário desse. Já não faria sentido um crescimento horizontal num cenário onde ambas responsabilidades, onde eu tenho queries por segundos aqui diferentes, mas assim, cara, muitos diferentes. A quantidade de query por segundo que eu vou ter em escrita e a quantidade de query por segundo que eu vou ter em leitura. Então, isso compromete o crescimento horizontal? Cara, demais. Compromete demais. Então, a primeira lição que a gente fala, uma das lições que a gente fala é, cara, vamos dividir as responsabilidades, vamos entender das peças que eu tenho, né, o que que precisa ser feito, né, e qual que é o volume que eu preciso ser, isso precisa ser feito, né, então, também isso é muito importante, né, então, a gente vê num caso do Instagram, por exemplo, eu vou ter, por exemplo, um load pools que vão responder com shapes diferentes, que é o case B, a representação do meu thumbnail e aonde eu vou ter necessidade de ter tráfego de rede com mais requests, na verdade, requests de longa duração para fazer payload de outra forma. Então, aqui, os meus requests, eles sempre vão ser de longa duração, né? Subir imagens aqui, cara, às vezes pesado, processamento vai ser distribuído. Não, e aqui, os requests aqui, eles são de baixa duração. Na verdade, tem que ser de baixa duração, né? Porque senão eu impacto o meu usuário final mas aqui eu vou ter muita gente também, muitos usuários consultando aqui para buscar imagens com mais frequência do que subindo então a gente traz até um negócio aqui, a gente quando vai trazer esse aspecto, a gente traz até uma palavra muito comum, a gente busca o ratio, o ratio de proporcionalidade entre escrita e leitura, que nesse caso está beleza. Tudo bem? Somente para talvez deixar um pouco claro alguns aspectos, quando você está falando em NodePulse, você está falando em conjuntos de máquinas com computação diferente, que cada um desses conjuntos, eles vão agir especificamente para casos de uso diferente. Então, eu poderia pegar uma máquina, um conjunto de máquinas tipo A, para responder o request longa, porque ela, computacionalmente falando, ela aguenta bem o request longa e o preço dela é adequado, inclusive, para o request longa. Por outro lado, não faria sentido eu ficar gastando computação com uma máquina de request longa para ficar fazendo processamentos pequenos de thumbnail. Ou seja, às vezes eu estaria gastando tempo, gastando até dinheiro à toa porque eu estou trabalhando dessa forma. Então, o que meio que você está querendo colocar aí dessas diferenças do case A com o B é, ao invés de você pegar algo e querer fazer tudo num lugar só, separa as responsabilidades, entendendo o nicho do que aquela aplicação vai fazer e organiza aquilo baseado no tipo de computação mais adequado. Você ia mais ou menos isso? Você resumiu super bem e foi excelente aí na sua observação. Cara, perfeitofeito É exatamente isso Por que isso? Por que isso impacta a minha réplica? Cara, isso impacta a réplica Na verdade, o case vem Justamente porque Para eu ter uma réplica saudável Não adianta eu entender O que a réplica acontece Se eu não entendo o que vai ser replicado Entendeu? Eu preciso entender o que vai ser replicado, entendeu? Eu preciso entender o que vai ser replicado para eu determinar o melhor uso do recurso. Aí entra a filosofia do Unix, né? A filosofia do Unix, qual que era? Cara, cada ferramenta dentro de uma caixa vai fazer melhor e unicamente bem feito o que ela faz. Então, eu vou ter... A gente falou de Node Pool, e realmente o Node Pool é um conjunto de servidores com características similares. Então, eu vou ter um Node Pool que vai responder requests de longa duração e eu vou ter outro Node Pool que vai atender requests de baixa duração. Eles vão ser diferentes, cada um na sua maneira, e eu vou crescer, replicar ali de forma orgânica, sem um cenário A impactar um cenário B. Fez sentido? Porque se eu tentar replicar esse case aqui de forma singular numa réplica, vai acontecer o seguinte, eu vou ter muita máquina e muito recurso computacional utilizado de forma incorreta. Mesma coisa, sei lá, eu tenho uma aplicação que tem um momento dela que ela vai fazer processamento para parte de machine learning, por exemplo. E outra máquina só vai receber requisição de servidor web. Não faz sentido eu querer botar a minha computação que vai resolver computação de servidor web para machine faz sentido eu querer botar a minha computação, que vai resolver computação de servidor web para machine learning ou vice-versa. Se eu botar meu servidor web, ou sei lá, vou minerar Bitcoin, sei lá, poxa, GPU pesado e etc. Não vou fazer isso para responder um Nginx no meio da história. Exatamente. Então, a RAP é muito sensível a isso, muito sensível, talvez essa é a questão que a gente precisa mastigar. A réplica é muito sensível ao conteúdo que eu trabalhar. Às vezes a réplica está sendo mal feita, porque eu não estou entendendo de fato o teor do que eu preciso processar ali, né? Então, talvez aí seja a maior lição. Talvez para a gente simplificar, talvez seja a maior lição da réplica. A maior dificuldade também, porque levando isso para os outros conteúdos que estão sendo ensinados aqui, isso aqui é muito importante, por quê? É isso que vai determinar, por exemplo, outros cenários, por exemplo, ah, Fernando, eu vou distribuir a minha computação, distribuir o meu software entre vários lugares e às vezes o comportamento não é o mesmo, eu tenho peças de software que tem comportamentos diferentes. Tudo bem? Perfeitíssimo. Obrigado por me complementar aí, cara, foi excelente.