Fernando, beleza então para réplica eu entendi então que esses meus recursos o meu conteúdo ele pode se replicar horizontalmente entre vários servidores, mas eu tenho que tomar um cuidado que eu preciso avaliar então qual que é o que eu vou replicar para eu não replicar incorretamente, um case A desse eu estaria replicando máquina, porque eu tenho um mix de requests diferentes aí, mix de comportamentos diferentes para dentro do mesmo software, eu poderia promover uma réplica incorreta. Num outro cenário, onde eu cego as responsabilidades e evito de ter um mix aí, eu tenho uma réplica mais saudável, faz mais sentido. Novamente, a lição da arquitetura de software, dividir para conquistar. Cara, posso apagar aqui? Pode sim. Hoje eu estou até fazendo um desenho, né? Você viu? Hoje eu estava meio didático. Eu vi uma aula sua e até fiquei com ciúmes. Cara, legal. Então, a replicação vai garantir que o workload possa ser executado entre várias máquinas distintas. Eu preciso tomar cuidado com o que eu vou replicar para não replicar de forma incorreta. Mas, o que acaba acontecendo é que esse meu conteúdo é replicável através de um componente externo, a gente pode chamar assim, de um componente externo que vai estar ali distribuindo o workload entre essas réplicas. Esse componente externo que distribui o workload, ou a minha carga de trabalho, em português, a carga de trabalho entre as réplicas, ele recebe um nome. Ele recebe o nome de balanceador de carga, ou load balancer. Todo mundo já deve ter escutado falar milhares de vezes. Beleza? falar milhares de vezes. Beleza? Então, o balanceador de carga acaba distribuindo esse conteúdo entre as minhas réplicas. O que acontece é que esse meu balanceador de carga, atualmente eu tive um nome aqui de balance, mas eu posso também ter um no master. Eu vou até descrever aqui. Posso ter um no master, vou até descrever aqui, posso ter um no master, para ficar bem claro, um no master, um multiserver, pode chamar assim também, que recebe essas requisições também e vai distribuir essas requisições dentro dessas réplicas. Então, a gente vê que isso acaba sendo muito comum. Esse cara acaba fazendo aqui. Aqui. Mas existe um problema aqui, Wesley. Quando ele faz isso, se de um lado a gente tinha... E eu vou até corrigir aqui, o padrão, até para a gente não confundir, load balancer é a expressão que vocês escutam bastante, mas o padrão é realmente um padrão chamado load balancer, de balanceamento de carga. Mas esse balanceamento, quando um no master, ou um root server, vai distribuindo as cargas aqui Entre esses servidores Eu vou chamar ele aqui de N1 F1 Servidor 2 Servidor 3 Quando ele vai fazer essa distribuição Se eu distribuo 5 requisições Para ele executar aqui Ele vai me devolver Essas 5 Então se euisições para ele executar aqui, ele vai me devolver essas 5. Então, se eu falo para ele, cara, executa para mim essas 5 consultas. Cara, você também, você vai receber mais 5, porque eu estou distribuindo de forma equalitária, mais 5 consultas. Esse cara aqui também, cara, você processa 5 para mim. Esse meu nó master que está recebendo isso, ele vai precisar receber essas respostas, faz sentido Wesley? perfeito da mesma maneira então, que eu mando para esses caras processarem, eles vão me devolver da mesma maneira então que eu mando para esses caras processarem eles vão me devolver para o NoMaster essas respostas quando ele devolve para o NoMaster essa resposta essa distribuição do workload entre as réplicas a gente chama aí de fan-out. Deixa eu escrever até aqui. Essa expressão eu também não conhecia. Fan-out. Vou trazer aí o fan-out. O que vai acontecer aqui? Eu vou distribuir o workload entre as replicas e aí ele vai trazer um problema de phone out. Isso vai acontecer, então, quando aquele servidor root, que é esse servidor em vermelhozinho aqui, ele distribui os workloads entre o backend, só que o backend, só que o backend precisa responder para o solicitante, que é esse nó master. Aí eu causo o impacto. Onde que é o impacto que eu trago aqui, Wesley? Eu trago o impacto em rede. Então, o fanout vai tratar quando os servidores dentro da minha réplica precisarem responder ao nó todas as requisições que são feitas e aí eu gero um gargalo nesse meu nó. Esse problema é o que a gente chama de problema de fanout, é o problema de engargalamento de rede. Engargalo de rede. Engargalo de rede. Beleza? O cara fala, pô, Sandro, mas isso faz impacto no meu System Design? Faz impacto no meu System Design. Faz muito impacto. Isso faz tanto impacto que alguns serviços gerenciados de nuvem resolveram resolver esse problema então que esses caras fizeram as réplicas eles entenderam que as réplicas eu replicar aqui pra executar o workload legal. Cara, era uma solução legal porque eu conseguia atender esse meu workload de forma distribuída. Mas na hora que eu precisava devolver para o meu non-master, isso era uma problemática porque trazia um problema de rede. E aí foi agregado um outro, na verdade, agregado, a gente vai chamar esse cara aqui, vamos continuar mantendo ele de root server, porque é até uma expressão legal, mas esse cara, ele era ele ele ele ganhou uma nova responsabilidade. Ele começou a quebrar essas responsabilidades. Lembra que eu falei do dividir pra conquistar? Ele começou a quebrar. E aí o que começou a acontecer? surgiu o intermediário, vou trazer aqui vou deixar assim para ficar mais simples meu desenho esse intermediário aqui não executava mais nada ele também distribuía, mas outro cara para distribuir ele distribuía na réplica no final das contas esses meus nodes eles estavam fazendo tudo aqui E aí o que a gente tinha? A gente acabava ganhando agora um outro cara que no balanceamento, na replicação, ele acabava sendo o responsável por pré-processar, opa, por pré-processar para mim as chamadas. Então, esse Node aqui, ele já não respondia, o root server já não recebia todos os processamentos da réplica. Então, isso aqui, Node 2 e esse Node 3. Ele dividia isso. E aí, Fernando, por que isso é importante? Cara, isso é importante porque você vê isso todo dia em serviços gerenciados, só que às vezes a gente não está ligando o nome à pessoa. Quando eu tenho múltiplas zonas e esses serviços são distribuídos, eles são distribuídos entre máquinas que vão fazer a agregação de serviços esses caras fazem a agregação para evitar que o tráfego total de rede chegue nesse cara esse cara também vai fazer a agregação do processamento esse cara também vai fazer a agregação do processamento. Esse cara também vai fazer a agregação do processamento. Então, para evitar o problema de fanout, que era o problema de gargalo de rede do root server receber tudo, esses servidores acabavam processando as queries de forma separadas durante as suas réplicas e aí servidores intermediários acabavam fazendo a agregação para devolver para o root server algo pré-processado e diminuir, então, o tráfego de rede para o root server. Fernando, aonde que existe isso? Eu já escutei falar disso, mas eu nunca vi uma implementação dessa. Existe um case famoso chamado Dremel. Opa, faltou meu R aqui. O Dremel é a base do BigQuery. Então, como que o BigQuery conseguia ser ágil? Como que o BigQuery, o Deo, consegue ser ágil? Tem várias coisas, lógico, dentro da arquitetura dele. Mas uma grande sacada dele, qual foi? Bem, eu vou resolver o problema do meu planalte, distribuindo entre outros grupos de nós, para reduzir o problema de tráfico de rede e vou fazer o processamento distribuído. Então, vou fazer que esse meu root server também não esteja engargalado para responder. Ele vai responder com menor intensidade. Isso daí. Então, um case famoso, o Open Source é o Dreamer. Então, quem for buscar aí, vai encontrar que o Dreamer faz essa implementação, tá? Então, aqui, ele vai reduzir pra gente assim, de imediato, ele vai reduzir pra gente o custo, né, dessa composição, e ele é um cenário legal porque, nas topologias de nuvem, isso é feito através do que a gente chama, né, de processamento zonal. Ele vai lá e você vê zonas distintas executando também, regiões distintas, executando workloads de forma paralelizada para eu ganhar processamento em réplica. Então, o fanout na cloud é tratado assim. Então, não basta eu replicá-los. Eu vou ter a divisão do processamento entre zonas distintas. E aí tem até algumas literaturas que chamam isso de root mixed também. Que eu tenho esses servidores de processamento zonais para balancear o tráfego. Wesley? processamentos zonais para balancear o tráfego. Wesley? Fernando, cara, isso é muito bacana porque muitas vezes a gente não percebe, a gente está usando nuvem e a gente não percebe que isso está acontecendo, porque é transparente normalmente para a gente. Para a gente, a gente tem o load balancer, mas o que está por trás do load balancer para aguentar tudo isso. Agora, uma pergunta, Fernando. Em relação a esse S1 e S2, poderia ser... Vou dar um exemplo muito simples. Eu tenho uma aplicação que pega um vídeo e gera um monte de thumbnail para esse vídeo. Um frame para cada vídeo. E eu faço os uploads, vão cair pra fazer o processamento. O root server ele manda a informação, sei lá, pro nó 1 de agregação. Esse cara, balanceia, manda pro S1. O S1 processa e fala assim, olha, esse aqui tá o link com os thumbnails. Acontece a mesma coisa com o 2. O 2 manda para a agregação. Quando o cara da agregação manda para o root server, ele junta um documento só, falando aqui está o resultado do processamento 1, aqui está o resultado do processamento 2, ao invés de ficar mandando um monte de processamento. Como é que funciona? Dá para fazer assim também. Dá para fazer assim também, tá? Dá para fazer assim, não é tão difícil a gente ver isso, tá? Faz sentido o que você está falando, é possível também fazer essa distribuição até para eu ter ela mais compartilhada entre os objetos de storage, né? É que a vantagem lá do objeto de storage, aí ele tem outras vantagens dele, né? Eu falei um exemplo muito ruim de imagem, mas poderia ser um processamento de qualquer dado. Um dado de qualquer forma, entendeu? Poderia. Não, isso está certíssimo, cara. Essa observação é super válida. Qualquer dado, de qualquer fórum, ele poderia ser separado assim, e essa é a grande graça dele, né? Porque aí a gente vai entrar lá no final, lá no final dessa conversa, a gente vai entrar num cenário onde eu vou ter os endereços onde meus dados já estão, já pré-armazenados de forma dividida, para eu poder fazer isso. Só que isso aqui também traz uma outra sacada. Sabe qual que é a outra sacada? Fernando, no desenho inicial nosso, quando a gente começou a desenhar em réplica, trabalhar com réplica, a gente começa, então, a pensar que eu preciso ter servidores com menor capacidade. Olha só que engraçado, né? Em vez de ter servidores com muita capacidade, eu tenho servidores com menor capacidade. Por quê? Porque aí eu consigo, num caso de falha, replicá-lo mais rápido do que um servidor maior. Certo? E eu tenho esses dados fatiados entre os servidores de uma melhor forma. E aí eles têm estratégias para que, durante a réplica, esses dados sejam fatiados dentro do system design. E aí o software que a gente conhece, software de banco igual o Mongo, certo? Que a gente estava falando hoje, né? Ele também usa estratégias de que a gente vai... Vou até adiantar, charge, né? Para poder fazer essa quebra de dados e essas réplicas funcionarem de forma mais inteligente, saca? Perfeito. Começou a fazer sentido para você o lance do charge? Não, totalmente. Totalmente. Tá? Maravilha. Aqui, a gente teria agora traz um outro problema. Fernando, legal. Se de um lado a gente resolve agora, traz um outro problema. Fernando, legal. Se de um lado a gente resolveu o problema de rede, recapitulando, eu tenho o problema do meu fan-out, porque a réplica, eu pensava em replicação, pensava em consenso do dado de estar distribuído de forma igual, eu tenho ideia de quais réplicas eu tenho, quantidade de servidores que eu tenho, responsabilidades que eu tenho, quantidade de servidores que eu tenho, responsabilidades que eu tenho, que eu preciso ter no software, entender que para essa minha réplica ser mais saudável ou não, qual que é o meu RPO, qual que é o meu RTO. Vimos aí um serviço de upload de imagem, cara, que eu preciso dividir as responsabilidades para que a minha réplica também funcione de forma igual, de melhor forma, independente do recurso que vai estar alocado. Eu também preciso entender que na minha réplica, quando eu repico o meu orquídeo para ser executado em algum lugar, eu também posso trazer um problema de fanout, e esse gargalo de rede é tratado através desses nós de agregações. Ele é muito comum, e aí o caso desse é o próprio Dreamer. Cara, eu acho que a gente, eu e você, a gente subestimou o resto do conteúdo, tá? Do tempo. Não, eu acho que, inclusive, é bastante informação aqui para um papo só, inclusive, porque esse assunto, inclusive, de agregação, root, entender como essas coisas, inclusive, vão longe. Então, eu acho que deu para pegar, acho que até agora. E eu acho que depois a gente pode continuar e estender em alguns outros pontos. Maravilha, perfeito. Perfeito, porque agora a gente já começa a trazer outros problemas que a replicação vai trazer a tona, igual a esse que eu falei. Cara, e se eu tiver muitos dados aqui para agregar? O que acontece na prática? Cara, eu estou tratando uma quantidade de dados absurda. O que vai acontecer? aí é onde entra as estratégias de sharding só que também tem um outro problema quando a gente fala de balanceamento, entra o estado o estado da sessão como que a gente resolve problemas de estado de sessão dentro de uma arquitetura então, aonde o cache deixa de ser uma estratégia legal e é uma estratégia legal? Como que eu fatio o meu cache? Então, acho que isso é o conteúdo que a gente pode falar na próxima aula. Faz sentido? Tranquilamente, Fernando. Acho que é isso aí. Beleza? O pessoal aí que está de casa, que está acompanhando em tempo real, fez sentido para vocês o que a gente coloca agora? Fez sim. Eu acho que a maior dúvida mesmo era aquilo que eu tinha já colocado em relação a essa parte da agregação. O cara um processo, dois processos, como é que funciona esse processo de agregação, mas eu acho que ficou bem mais claro agora, Fernando. E o Open Source do Dream é um negócio muito lindo de ler, então quem tiver a oportunidade para dar uma lida aí, entender como que ele faz isso internamente, ele é bem legal, tá? Show de bola! Então, pessoal, estamos encerrando mais uma aula aqui com o grande Fernando, trazendo muitos detalhes. Uma coisa que eu acho interessante também em tudo isso é que, acredito que muita gente, inclusive, que já trabalha em muitos pontos, em projetos de arquitetura, já está cansado de ouvir em horizontalizar, em verticalizar, mas a gente acaba percebendo que, cada vez que a gente vai mais fundo, a gente começa a se deparar com esses pontos mais lógicos. Quanto menor o meu tempo de desastre, de recuperação, o ponto de recuperação mais barato, o tipo de node pools que você pode trabalhar. Então, não é simplesmente falar dá para escalar horizontal e vertical, botar mais máquina um lado da outra. Não. Tem o tipo de computação, o tipo de solução que você tem que entender para desenhar qual é a forma de horizontalização. Esse que é o maior ponto. Exato. E a replicação é impactada justamente porque às vezes a gente não conhece o software. Esse é o grande problema. E é isso aí. Às vezes a gente aqui, muita gente aqui vive isso. A gente vive isso geralmente no nosso dia a dia. Cara, recebe o software e o software está sendo executado e aí, na verdade, o cara está com uma bomba no colo, né? E a bomba no colo é, cara, eu preciso de métricas do meu software para saber se ele está executando, porque, lógico, todo o system design, quando a gente volta para a prancheta, no início, deveria haver uma atividade anterior que a gente nunca fala. Os objetivos de níveis de serviço nunca são tratados nesse momento. São sempre tratados quando o software vai para a produção. E aí alguém vira e fala, cara, eu preciso rodar nessa condição e esses são os indicadores que eu quero. Cara, mas isso não foi tratado lá na prancha que ela traz. Muitas coisas começam a deixar de ser respondidas e até monitoradas. Quando a gente fala em System Design, também preciso trazer possibilidade de monitorar o software, essas peças de software, quando ele está em produção. Então, também preciso trazer na mesa isso. Cara, como que eu trato meus SLOs? Ou, nem preciso falar dos meus objetivos. Como que eu trato meus indicadores, meus SLIs aqui, agora? Se eu não conheço isso, cara, eu vou falar de indicador de serviço quando o software for para a produção. E aí, às vezes, eu não consigo nem mais obter métrica. Volta lá e reescreve uma parte do software, faz um ticateio, como a gente fala em espanhol, cara, faz uma gambiarra para eu obter os indicadores que, às vezes, nem são satisfatórios, porque nem toda peça de software precisa ter os mesmos indicadores de monitoramento. Se isso é algo mais importante ainda de tudo o que a gente falou, monitoramento. Se isso é algo mais importante ainda de tudo o que a gente falou, acho que é isso que eu acabei de falar agora. Nem todas as peças de software precisam ter os mesmos indicadores de monitoramento. E quando a gente faz isso, a gente acaba misturando o alho com o bugalho e dando respostas incorretas sobre os indicadores de qualidade de software. E você falou uma coisa de ouro aqui, Fernando, que é, um bom system design, né, ele já começa a pegar quais as condições que você espera que o software rode, porque isso depende, porque isso afeta a forma que o software vai ser desenvolvido, né? Às vezes você não faz isso. Quando vai pra produção falar, mas eu queria decidir, assim, ó, do jeito que foi desenvolvido, não dá para cumprir esses requisitos. Essa frase que você falou, quantas vezes eu já escutei isso. Cara, do jeito que está desenvolvido, a culpa não é nem do dev, caiu no colo dele e ele fala, cara, olha, tem tais, eu preciso de tais indicadores dessa peça do software. Do jeito que está, não consigo. Vamos tentar fazer aqui uma maneira de encontrar esse indicador aqui, mas esse indicador eu não consigo responder. O pior é quando ele consegue responder e falar, eu consigo, está aqui o dado, mas eu não consigo melhorar isso, esse tempo de resposta, porque o software não foi projetado. Se você tivesse falado para mim, antes de começar, eu tinha feito uma outra arquitetura aqui, e essa arquitetura dá, mas agora, se quiser, tem que voltar a desenvolver. Pode acontecer também. Por isso que existe uma abordagem que eu adoro, mas a gente pode falar depois disso, que é a arquitetura middle-out. Você falou um pouco, inclusive, na primeira aula. Isso para mim é fantástico.