Outra verdade absoluta. Quanto maior a consistência que eu vou buscar e quanto maior a disponibilidade que eu vou buscar, mais caro é a minha solução. Não tem como eu fazer isso barato, Fernando? É que o barato é relativo. E eu vou falar porque é relativo já já. Mas quanto maior a consistência e maior a disponibilidade, maior o meu investimento. Dou dois exemplos aqui. Cara, quando eu sento com um cliente, normalmente há duas perguntas básicas que eu faço. Qual que é o MTTR e o RTO dessa solução? Ou seja, quanto tempo eu aguento uma falha e em quanto tempo eu preciso voltar para ter o meu serviço estável. Ou preciso reestabelecer o meu serviço. Então, isso é muito particular. Eu sou um serviço bancário, possivelmente eu vou ter que ter lá um ou uma solução de arquitetura que me traga essa vantagem, esse tempo muito curto, ou eu vou ter que construir, possivelmente, um DR. Seria muita gente fazendo. Cara, eu não meço na minha solução, mas eu vou lá e construo um DR. Às vezes, eu vou escrever o software do passado, é caro. Então, o cara vai lá e mete um DR. Certo? Faz uma réplica. Mas aí você viu. Se tornou um investimento muito caro. Então, a gente precisa entender que a gente vai ter que pesar, vai ter que entender qual o trade-off em particular para aquela minha solução para eu entender para qual lado eu vou. Certo? trade-off em particular para aquela minha solução, para eu entender para qual lado eu vou. Quando a gente... Esse teorema de CAP, ele acaba a gente usando no dia a dia. Tenho certeza que mais de 90% deve ter utilizado ele aqui sem saber que ele existia. Usava lá, usava... Porque ele é baseado num negócio que nós seres humanos temos. Apesar que eu estava falando com o Wesley que não tinha antes da gravação mas a gente tem bom senso então a gente usa do nosso bom senso pessoal e usa da necessidade de negócio para entender para qual lado eu vou pesar só que a gente tem soluções quando eu vou, por exemplo, pela consistência eu vou ver soluções do Google, por exemplo, pela consistência, eu vou ver soluções do Google, por exemplo, não sei se todo mundo conhece o Spanner, que ele vai tratar o particionamento de rede, buscando o quê? Buscando trazer o dado mais atualizado, prezando a idade do dado, um timestamp. Até para eu falar de forma mais simplista. E aí o timestamp, o registro que ele for considerado mais velho, ele vai acabar, num consenso global do meu cluster, sendo mais válido. Então a gente entende, para determinar, a gente acaba pesando a consistência do dado, tratando de forma diferenciada a consistência para eu garantir mais a disponibilidade. Então, eu diminuo a consistência, deixo para um algoritmo X determinar o que é mais consistente, torno a solução mais barata, mas a minha disponibilidade é imediata. Se eu não fizesse isso, eu tivesse que ter uma réplica fiel aos dados de forma distribuída, o que ia acabar acontecendo é que a minha disponibilidade poderia ser prejudicada, porque quanto mais réplicas eu tenho no sistema, significaria que é mais caro eu promover a escrita das réplicas dentro do cluster. Por isso que eu preciso pesar isso da forma satisfatória. Em sistemas pequenos, talvez isso não seja visível, mas em sistemas de escala, que é esse que a gente está falando, cara, de usar um YouTube, de usar um Splanner, de usar esse tipo de solução, a gente está falando de software global. De usar um software, por exemplo, desses que a gente está falando aí, vários outros, redes sociais super importantes. Então, cara, como que eles pesam isso? Então, eu preciso entender que, às vezes, eu escrevo em várias réplicas, torna a escrita muito cara e vai me levar à indisponibilidade do dado lá na ponta. Então, às vezes, para não provocar a indisponibilidade, eu vou entregar uma consistência que a gente chama de consistência eventual. Fez sentido, Wesley? Totalmente. Porque vamos imaginar que a gente tem réplicas de uma rede social rodando em todo mundo, para todo mundo acessar mais rápido, alguma coisa desse tipo. Alguém mudou o nome do perfil. Até todos esses dados sincronizarem, eu tenho duas opções. Uma é eu acessar a minha rede social e falar, sistema indisponível. Por que vai estar indisponível? Porque ele quer ser disponível apenas quando os dados estiverem consistentes. Como os dados estão ainda inconsistentes, porque eles não foram totalmente sincronizados, eu não mostro essa informação. Se eu trabalhar com consistência eventual, eu mostro informação, mas para o Fernando pode estar aparecendo o meu nome antigo. Para uma rede social, isso pode parecer algo até inocente. Ah, eu consigo viver com isso. Agora, vamos imaginar que você está na frente de um caixa eletrônico. E daí você vai sacar o dinheiro. E os dados não foram ainda sincronizados. Você acha que o banco vai deixar você sacar dinheiro acima do seu limite porque ele não conseguiu sincronizar os dados? Provavelmente não. O que o banco vai fazer? Eu não consigo sacar o dinheiro agora. Ele vai ficar indisponível porque ele preza a consistência. Exato. Ótimo. E aí, acho que você chegou num ponto muito importante. Você deu um exemplo aí, e aí as pessoas podem falar, Fernando, mas quando eu não posso ter a consistência eventual, eu preciso ter uma, vamos falar, uma consistência forte. Vamos chamar assim? Consistência. Consistência consistente, né? Uma consistência consistente, cara. Como que eu vou ter isso? Cara, eu dou um exemplo. Sistemas de fila. De message queue. Cara, o dado tem exemplo. Sistemas de fila. De message queue. Cara, o dado tem que ser consistente. Se eu vou consumir a fila, pelo amor de Deus, o dado tem que ser consistente. Então, tem que ter o arrival message, cara, o mais consistente possível. Faz sentido? Totalmente. Cara, dá outro exemplo. Configurações em storage. A configuração em storage, às vezes o comportamento altera baseado em configuração. A minha consistência tem que ser constante. Então, nesse caso, a gente usa algo, uma estratégia, a gente precisa saber isso como arquiteto, que se chama consenso distribuído. Você acabou ensinando isso para eles? Não. Consenso distribuído. Quando eu vou ter a consistência consistente, forte, gostei desse cara aqui, deixa eu colocar entre... Quando eu vou ter a consistência consistente, forte, vou buscar o consenso distribuído. Por quê? O que ele vai fazer para mim? Ele vai permitir que eu faça uma leitura de um registro após eu garantir na rede que a escrita dele é a mais satisfatória. E aí existem alguns exemplos de algoritmos muito famosos. O primeiro que eu acho que é importante a gente depois fazer uma leitura, sugiro todo mundo fazer uma leitura dele, é o Paxos. Esse algoritmo que é super famoso ele faz. Primeiro, o que ele precisa resolver? Lá para frente, a gente tem um padrão que a gente precisa entender, esse padrão de contação, de distribuição de registro. Mas eu vou chegar lá. Para mim também ele é um pré-rec para eu poder fazer o desenho. Mas o que acontece? O que acontece é que dentro de uma rede, quando eu vou compartilhar a escrita e a leitura num nó só, eu vou acabar tendo máquinas com a mesma responsabilidade. O que a gente faz em sistemas de grande porte quando eu vou fazer o system design? Eu uso a lei 1 da arquitetura de software. A lei 1 é, cara, eu vou distribuir os comportamentos por hardware. Eu vou distribuir os comportamentos. Eu vou dividir para conquistar. A lei 1 da arquitetura é dividir para conquistar. Então, eu vou buscar os meus recursos mais próximos da operação que ele faz. Vou dar a César o que é de César. Máquinas que vão fazer escritas, eu vou dar escrita. Máquinas que são para leitura, eu vou dar características delas de leitura. Isso é importante para eu também não sobrecarregar o mesmo ambiente com dois comportamentos que eu espero no meu sistema que são distintos e dão respostas distintas. Eu vou falar disso mais para frente para vocês. Mas o que o Paxos vai fazer? Esse cara só vai dar o retorno para o meu cliente, para quem está fazendo o request, quando todo mundo dentro do ambiente de réplica estiver de acordo sobre tal registro. Então ele vai buscar o consenso distribuído. É daí que vem o nome. Então, você imagina que entra alguém aqui dentro, um terceiro na live, e fala para mim, para o Wesley, Wesley, 2 mais 2 é 5? Aí o Wesley fala, não, é 4. Aí eu vou lá e falo o que é? É. É 5. A gente entrou num falo o que é? É. É 5. A gente entrou num consenso? Não. O meu cliente recebe resposta? Não. Por isso que os nós baseados em consenso distribuído, normalmente, eles têm mais de 5 máquinas. Sempre um número ímpar, mas normalmente mais de 3. Deixa eu corrigir o que eu falei. Entre três e cinco. Por que isso? Ímpar e três e cinco? Porque se uma máquina cai e o meu cliente vai lá e faz uma pergunta para o Wesley e para o Fernando e a gente não entra em acordo comum, o meu usuário não tem resposta. Então, ele não tem consenso. Quando eu tenho um cluster com cinco máquinas e uma cai ou uma cai, o que vai acabar acontecendo? Cara, por mais que uma caia, eu vou conseguir entrar num consenso, por quê? Cara, porque eu vou ter a resposta que sempre vai tendenciar algo. Lembrando que, lógico, uma das duas máquinas, uma dessas máquinas vai ser o Libre. Então, numa réplica geral, como que é escolhido? O Paxos, os algoritmos de consenso, o que ele vai fazer? Ele vai ter uma máquina que vai receber a requisição do meu usuário e vai distribuir para outros que vão executar réplicas. E aí as máquinas que são réplicas vão ser as máquinas questionadas. Então, entre um líder aqui, pergunta para mim e para o Wesley que somos o quê? As réplicas. 2 mais 2 é 5. E aí as máquinas, as réplicas, não entram em acordo comum. E aí o líder fica sem resposta. Quando eu tenho mais de três máquinas, isso é impossível de acontecer. Por quê? Porque eu sempre, em número 1, vou ter o desempate do consenso. E aí é o que se busca, esse algoritmo de consenso distribuído. Fernando, mas isso é importante? É muito importante. Os bancos de dados, as estruturas de armazenamento que eu tenho distribuídos, todos eles são baseados em algoritmos de consenso. O Pax é um exemplo dele. A gente tem outros, tá? Aqui, pra até outras derivativas do Pax, né? Tem multipax, né? Porque, cara, puto Pax não tá mais pós-satisfatória. Depois eu posso falar disso, tá? Tem singlepax, tá? Tem um famosíssimo que a galera gosta de falar dele que ele é utilizado dentro do Kubernetes lembra aí Wesley, qual que é? Havk Havk Consenso é o Havk Consenso inclusive ele é utilizado se eu não me engano também no utilizado, se eu não me engano, também no RabbitMQ. Se eu não me engano, ele é usado no RabbitMQ. Exato, exato. Se eu não me engano, também, o Apache Kafka usa um cara que chama Zookeeper para fazer esse processo de Service Discover. O Zookeeper, se eu não me engano, também usa a HAPC. O Consul também usa a HAPC. Usa? Então, algo importante que eu tenho em mente, cara, é super importante. Eu preciso ter isso em mente, mas por um outro fator que me impacta muito quando eu vou fazer o desenho. Eu falei aqui da rede, não falei anteriormente da rede? Eu vim aqui e falei aqui para a gente. Olha, gente, cuidado com a rede. Rede é tudo. Então, vamos dar um exemplo simples. Eu estou fazendo um desenho de um cluster Kubernetes, vou colocar minha solução em container, aí vou jogar num cluster Kubernetes, vou colocar minha solução em container, aí eu vou jogar num cluster Kubernetes, aí alguém resolve fazer a instalação dele na mão, sei lá qual é o motivo, alguém resolve criar os master nodes em regiões distintas. O que vai acontecer aqui? Aqui, naturalmente, nesses algoritmos aqui, para eu poder obter o consenso, eu vou ter uma escrita entre o líder e as réplicas. Para eu poder ter os meus dados atualizados da forma mais rápida ou em consenso mais rápido, eu vou ter lá a escrita entre eles. Então, se eu entendo como isso funciona, eu vou evitar, incluso de separar essas regiões, esses itens da peça. Então, possivelmente, quando você olhar na documentação dessas ferramentas que o Wesley falou, numa arquitetura de referência, sempre vai pedir para eu jogar dentro de uma mesma região. Por quê? Para eu não ter o uso de rede de forma incorreta e não impactar a resposta para o meu usuário final. Por quê? Porque se eu não poder entrar em consenso com as minhas réplicas da forma mais rápida, significa que o meu usuário solicitante vai ter um tempo de resposta mais sobrecarregado.