porque a gente quer evitar na verdade o que a gente chama de spot é o single point of fail porque eu quero evitar um ponto único de falha Eu quero evitar um único ponto de falha, mas por quê? Cara, por quê? Se eu tenho um sistema que carrega um só workload, na verdade, um recurso, até para eu usar o mesmo linguagem que eu utilizei ali, se eu tiver um recurso que trabalha com só workload, em um momento específico, se esse recurso vir a provocar um downtime, eu acabei de ir com um recurso para fora. O que eu quero dizer com isso, Fernando? Então, você imagina o seguinte, eu vou até fazer um desenhozinho aqui, você imagina que eu tenho um servidor aqui, esse servidor me responde 3 mil queries por segundo. Certo? Beleza? E eu tenho aqui uma quantidade de usuários felizes, que estão invocando, na verdade, esse servidor para eu ter essa resposta. Quando isso acontecer, o que a gente quer evitar? A gente quer evitar de fato que esse meu servidor aqui, que me responde 3 mil KB por segundo, esteja vulnerável. O que acontece aqui é que, quando eu tenho esse cenário, de um só servidor respondendo a essa questão do usuário, eu vou ter um spot, esse único ponto de falha aqui. Se esse cara falhou, todos os serviços, 3 mil quests por segundo, deixam de ser respondidas. Então, quando a gente cria réplicas, quando a gente distribui essa minha carga aqui, dessas 3.000 queries por segundo, para outros recursos computacionais, o que a gente acaba fazendo é dividindo o risco. Então, se eu tenho um cenário desse daqui, ó. Ué, Aziz, se meu desenho estiver muito ruim, você me avisa, tá? Porque eu sei que você é o rei dos desenhos, tá? Não, fica sossegado que não tá... não tá... tá no mesmo nível que o meu. Então, opa. Então, eu poderia ter um cenário desse, aonde o meu usuário X aqui, certo? Ele está... Opa. Esse meu usuário x aqui, ele está tendo a carga dele distribuída entre vários servidores. Quando eu faço isso, a gente fala que eu reduzi o meu ponto de falha porque quando eu tinha uma falha eu tinha uma falha específica aqui não é um ponto de falha específica aqui é um spoof aqui na verdade eu acabei fazendo é distribuindo a carga entre vários servidores a gente escuta muito comum escutar no mercado, nome para isso. Em System Design a gente dá um nome para isso. A gente fala que a gente tem um failure domain. Então a gente tem um failure domain aqui e aí eu agora tenho vários failures do domain agora. Então, maravilha. Então, o que acontece aqui? A gente vai buscar utilizar a replicação para garantir que eu continue mantendo a resposta às minhas demandas de serviço, né? Quando isso acontecer, né? Então, primeiro acontece aqui, né? Esse failure domain aqui que eu vou ter, ele vai eliminar o single point of failure, que é o SPOF que estava aqui, ó. No caso, eu tinha um SPOF aqui que se tornava crítico. Beleza? E aí, o que a gente acabou fazendo é dividindo o nosso workload através da replicação, a gente acabou dividindo o nosso workload entre os diferentes FDs. Vou começar a chamar de FD a partir de agora. E aí, lógico, a graça disso é que quando eu estou fazendo isso, eu começo é trazer um novo cenário na esse cenário aqui permite executar o que a gente chama de escalonamento aqui horizontal Beleza? Então, a gente prioriza a réplica para eu ter um escalonamento horizontal. Certo? Mas por que isso, Fernando? Então, escalonamento horizontal. Por que isso? Cara, isso é um bom cenário porque no cenário onde as minhas quantidades de query por segundo também venham a ultrapassar o que eu tinha previsto, eu adiciono um número de nós, um número de computações de forma horizontalizada, e aí é onde eu tenho liberdade de adicionar novas máquinas ao meu cluster para responder essa quantidade de serviço. Quando eu não faço isso e preciso adicionar mais memória e adicionar mais processador, a gente chama isso de escalonamento vertical, certo? Então, eu vou lá e aumento os recursos da minha máquina para eu poder responder essa minha demanda. Então, a graça aqui é que eu vou aumentar a quantidade de memória e CPU, mas eu mantenho o meu SPOF. Eu mantenho ainda o meu ponto de falha. Cara, isso funciona para todos os cenários? Não, nem todos os cenários eu vou conseguir crescer verticalmente, mantendo o meu serviço online. Nem todos os cenários eu vou conseguir distribuir a minha escala de forma horizontal. Isso é importante a gente saber. Então, a grande graça aqui no cenário abaixo é que, qual que é? Essa distribuição vai permitir eu evitar a degradação do serviço, né? Num caso onde eu tenha gargalo, eu consigo evitar a degradação do serviço, o número de requisições é distribuído de forma quase qualitária ou comum entre as máquinas que fazem parte do meu fake domain. Então, isso é muito legal. Dado isso, dado que eu consigo entender qual que é a quantidade de queries por segundo que eu tenho, eu consigo determinar qual que é a quantidade de recursos que eu tenho. Mas o que acontece quando um servidor desse vem abaixo? Ou seja, quando eu tenho um downtime. Então, cara, eu vou ter um downtime específico e esse servidor aqui não vai mais responder. Nesse cenário, a grande vantagem que eu tenho é que eu ainda continuo respondendo a minha quantidade de query por segundo. Lógico, eu vou aumentar a quantidade, vou criar um gargalo de um lado aqui entre um servidor 1 e um servidor 2, vamos chamar assim, um servidor B e um servidor C, mas eu não vou deixar de responder. Num cenário onde eu tenho escalonamento vertical, se esse cara vai por água abaixo, o que acaba acontecendo é que eu não respondo nenhuma requisição. Aí isso volta à conversa inicial que a gente estava tendo no nosso primeiro encontro. Às vezes é melhor eu responder com atraso a que eu não responder. E, lógico, em alguns cenários eu vou preferir não responder imediatamente do que eu criar um gargalo excessivo. Está ok? Então, de forma simples aqui, o que vai acontecer quando esse cara cair é que eu não vou ter uma quantidade X de queries por segundo sendo respondida, vou ter um impacto. O que acaba acontecendo normalmente aqui é que a gente vai tentar uniformemente no design do nosso sistema estar respondendo essa quantidade de 4 por segundo. Mas, naturalmente, o que a gente pede em alguns cenários é que eu tenha dois votos extras. Fernando, mas isso acaba se tornando um pouco mais caro. E a gente chama isso, até quando a gente faz essa divisão equalitária, a gente acaba até chamando isso de N mais 2. Por que N mais 2? Porque a gente sugere que para sistema de missão crítica, normalmente num sistema de design, eu deveria ter um nó para manutenção e um nó para atualização. Ou para efeito de falha, a gente também considera ele, né? Mas o que a gente precisa entender aqui é que a gente vai precisar dividir um pouco essas responsabilidades aqui entre as regras, né? Fernando, mas nem sempre essa divisão que a gente faz aqui ela é sensata, ela é comum. E aí, isso é algo que aparece muito no meu dia a dia. Fernando, eu já sei, eu vou dividir esses meus servidores de forma idêntica e beijo, me liga. Não, nem sempre isso vai funcionar assim. Nem sempre isso aqui vai ser legal. Quando nem sempre isso aqui vai ser legal? Vai acontecer um cenário, eu vou até escrever aqui, então, vamos imaginar um case aqui para vocês. Está me acompanhando aí, Wesley? Está me fazendo entender? Sim, Fernando. E eu acho que até antes do case já surgiu isso aqui é o seguinte, você consegue explicar um pouquinho mais sobre o N mais 2 o que é manutenção e o que é atualização e etc? Lógico, lógico então o que acontece? o que a gente faz? quando a gente quer garantir respostas em workloads críticos, a gente sugere que, todos os nós que eu tenho aqui deveria ter a capacidade de responder todos os workloads de forma idêntica, independente. Então, se um cara desse cai, eu deveria ter outras máquinas que em conjunto me respondessem a quantidade de 3 mil queries por segundo. Até aí, tudo bem? Perfeito. Maravilha. O que a gente normalmente sugere em sistema de missão crítica é o quê? É que a gente tenha dois nós extras para receber esses workloads. Esses dois nós extras deveriam ter também a capacidade de garantir que dentro de um cluster, num cenário específico de que eu tenha a manutenção de um dos clusters ou a atualização de um dos clusters, o outro nó pudesse receber de forma equalitária ou conseguisse responder a quantidade de queries por segundo sem desbalancear a carga dentro do cluster. Então, o que a gente faz? A gente sugere, normalmente, N mais 2. Por isso que, normalmente, quando você fala cara, eu vou provisor um cluster XPTO na nuvem, normalmente, quando você fala, cara, eu vou provisor um cluster XPTO em um serviço gerenciado, você vai ver que o número natural sempre vai ser N mais 2. Então, por exemplo, eu vou criar um cluster num serviço gerenciado de Kubernetes, ele sempre vai me dar um número mínimo de 3. Já viram isso? Sim. Ele sempre vai fazer isso. Ele sempre vai fazer isso, porque ele vai entender o nó que você está implementando, o primeiro nó que ele vai responder, ele vai responder sem gargalo ao workload ali naquela máquina. Mas é o que ele vai fazer através do sistema de balanceamento e ele vai distribuir ele de forma igual. Certo? Para ter uma garantia, a gente indica que esses dois servidores extras se tornam caros, se torna caro. Em algumas nuvens, o que a gente chama de superclusters, eles nem implementam essa regra. Eles fazem normalmente N mais 1. Eles fazem o cálculo de distribuição e qualitário e colocam mais um servidor extra para um caso de atualização. Por que acontece isso? Porque se eu estiver fazendo atualização e eu precisar distribuir os meus usuários e meus workloads enquanto isso está acontecendo, eu não tenho impacto no usuário final. Ele vai distribuir a minha carga e o meu usuário não vai sentir essa atualização. Então, é aí que está a mentalidade dessa quantidade do N mais X, tá? Nos serviços gerenciados, normalmente você não precisa se preocupar nisso, porque já está acontecendo isso, às vezes, de forma automática, tá? Na maior parte deles, tá? Em alguns, não. Em alguns, tem incluso que escolher o que a gente chama de scale para que isso não tenha impacto. Por que é importante isso, Fernando? Por que é importante isso? Eu acho que, não sei quem mandou essa pergunta, mas é muito relevante. Há um outro fator no system design que a gente não está considerando aqui ainda. O provisionamento do recurso, num caso de falha, tem um custo. Alguns usuários me perguntam assim, cara, quanto é o tempo de eu subir em scale um novo nó para eu desafogar a quantidade de requests que eu vou ter distribuída nos servidores de forma apagada? Esse tempo, às vezes, pode ser crítico o suficiente que eu vou ter distribuída nos servidores de forma aparente. Esse tempo, às vezes, pode ser crítico o suficiente para eu poder perder, por exemplo, uma operação, uma venda. Então, normalmente, para a gente evitar isso, a gente mantém servidores sobressalentes. E aí, esses servidores sobressalentes é o que a gente computa lá no mais dois ou mais um. Fez sentido o que eu estou falando? Perfeito, Fernando. Fernando, aonde a gente vê isso muito comum? Ah, em casos de DR. Arquiteturas de sistema onde eu tenho que fazer DR, às vezes eu não tenho como fazer DR desidratado. Já escutaram essa expressão? DR desidratado? Se o pessoal puder responder aí no chat para