Há outras considerações que talvez, vamos falar aqui, para 80% do público que está escutando aqui, não vai fazer sentido. Para 80% do público não vai fazer sentido. Mas o cara que vai estar lá rodando on-premise, ele precisa entender outras coisas. Ele precisa entender que a gente não pode esquecer que há condições naturais do hardware. O meu software ali vai estar rodando, a minha solução vai estar rodando. E naturalmente, eu vou escrever até isso. Naturalmente, o hardware... Não fiz curso de digitação, tá? O hardware perde performance. Isso é natural. O hardware perde performance. Precisa entender isso. Ele perde performance e o hardware quebra. O hardware quebra. Então, eu estou falando de uma forma bem simples, porque é assim que a gente tem que entender quando eu vou fazer o design. O hardware vai deteriorar, ele não vai dar a performance que eu estou buscando. E ele vai deteriorar por algumas condições muito básicas, quando quem está em ambientes vívidos precisa entender. Primeiro, por aquecimento natural. Então, a gente faz em alguns cenários, a gente faz controle em curso do aquecimento do hardware para evitar isso. A gente sabe que a eletricidade pode ser um outro problema. A eletricidade estática é um problema. A vibração é um problema. Mas as condições externas também impactam o meu software. E eu ia falar colocar aqui como a falta de energia correta, problemas de cabeamento. Problemas de cabeamento, Fernando? Você já viu um vídeo do Google, não sei se todo mundo aqui já viu, que tem um tubarão Wesley comendo um cabo? Nossa, esse eu não vi. Nunca viu? Nunca vi. Eu vou mandar o link para vocês depois aqui, se anexa junto para o pessoal. É um barão, ele está comendo um cabo. Ele está comendo um cabo que ligam duas regiões distintas. Vem cá, você que é o cara que está desenhando a solução para o Google De infraestrutura, beleza? A rede é software hoje A rede não é mais A rede do passado Tudo é software no Google Na AWS tudo é software Na Azure tudo é software Você vai construir um software Imaginando que vai ter um camarada Comendo seu cabo? Gravaram um vídeo disso, desse tubarão comendo o cabo. Então, você vê, o hardware vai deteriorar. A gente vai precisar entender isso. Beleza, Fernando, maravilha. Entendi essas premissas. Quais premissas a gente deveria considerar além dessas? Que eu, como arquiteto, vou desenhar que a minha filosofia deveria entender. A gente saindo dessas premissas que são físicas, e retomando aqui as premissas que eu falei, as variáveis que são importantes para entender, a escala, que tudo vai falhar em escala, a minhaáveis que são importantes para entender, a escala, que tudo vai falhar em escala, a minha memória que é lenta, como fazer as coisas da forma mais satisfatória, que a minha rede eu preciso cuidar com parcimônia, utilizar ela com parcimônia para não ter impacto em latência, que tudo no meu sistema de design vai ser acumulativo, qualquer consulta vai sobrecarregar outra consulta. A gente vai gerar um funil. Isso vai impactar o tempo de resposta do usuário final. O meu armazenamento vai ser outra variável importante ali. O que meu radar, por mais ridículo que é isso para quem vai levar para a nuvem, mas para você entender que isso vai quebrar, eu preciso entender as minhas consultas. mas vamos entender que isso vai quebrar, eu preciso entender as minhas consultas. E quando a gente fala de consulta, eu tenho uma máxima, não sei se todo mundo vai respeitar essa máxima, mas eu prefiro, Wesley, ter um resultado degradado que um resultado em atraso. Quer escutar essa máxima? Exatamente isso. Uma coisa que normalmente eu falo, principalmente quando a gente está falando de micro serviços, é que às vezes a gente tem um problema que o microserviço A chama o B, que chama o C, que chama o D, mas o D está lento. Aí o D deixa o C lento, que deixa o B, que deixa o A, e as informações simplesmente não chegam. Se o D, lento, ele já falasse, não consigo mais receber requisições, e retornasse um 500, todo mundo não ficaria lento. Você conseguiria tomar uma decisão de simplesmente esse cara está fora, então eu vou mostrar a informação da forma como eu posso ou de alguma forma. E eu não vou, na realidade, atrasar essa informação para o meu usuário final e não vou gerar um efeito dominó. Então, normalmente o que eu falo é melhor um microserviço fora do ar do que um microserviço lento. A gente tinha conversado, hein? É, a gente tinha conversado. Mas olha só. É melhor... É melhor falhar que esperar muito. Em todos os sistemas grandes que eu venho trabalhando, eu sempre vejo os arquitetos terem esse comportamento. Cara, é melhor falhar rápido que esperar muito. Por quê? No caso de microserviço, eu poderia buscar um circuit breaker, né? Da forma mais satisfatória. Agora, não eu esperar um tempo até eu provocar um timeout, para depois buscar um surface breaker e impactar o meu usuário lá na ponta. Então, falha rápido. A consulta tem que falhar rápido. E se ela não falhar rápido e eu tiver que mudar uma condição de resposta, dar um resultado degradado é melhor que um resultado em atraso. Então, para mim, essas premissas têm que estar no papel, incluso quando eu vou escolher, por exemplo, a minha solução de armazenamento de dados. Eu vou usar um banco de dados, antecipando aqui algumas coisas. Eu vou utilizar aqui um banco de dados que eu vou ter réplica, não vou ter réplica, que eu vou ter charge, não vou ter charge, que tipo de réplica que eu vou fazer, que modelo de consenso que eu vou ter charge, não vou ter charge, que tipo de réplica que eu vou fazer, que modelo de consenso que eu vou fazer. Começa a fazer sentido? Totalmente. Então, eu preciso ter isso em mente antes de sempre começar a desenhar os quadradinhos, num bom sentido. Adoro. Olha a minha lousa lá atrás. Dia inteiro fazendo. Então, para mim, em consulta, eu tenho essas duas máximas aí. E obrigado por você estar... Aprender com você. A segunda. É melhor a gente falhar rápido do que esperar muito. Beleza? Então, isso é excelente para o usuário final. É isso que a gente precisa entender. Só que quando a gente chega aqui, Wesley. Quando a gente chega aqui, a gente chega aqui, Wesley quando a gente chega aqui a gente chega, algo que eu li no material deles aqui, eu achei fantástico isso mesmo pra eles pode falar palavrão aqui? achei foda achei foda esse teorema de CAP aqui e acredito que todo mundo lembre aí, né, do teorema de CAP, mas eu vou recapitular pra todo mundo para deixar claro, porque algumas literaturas não deixam tão claro, então eu vou deixar bem claro o que é aqui e por que ele casa aqui, quando a gente chega no momento da consulta, por que ele é algo importante. O Teorema de Kapp é separado, igual o desenho diz aqui, o super desenho bonito, eu sei dele, entre consistência, disponibilidade e tolerância ao particionamento. Então, consistência, quando a gente fala de consistência, a gente está falando que todos os nossos nós de um sistema para a gente tem que ter todos os dados no mesmo tempo. Todos nós, dentro da minha estrutura, tem que ter todos os dados, os mesmos dados, ao mesmo tempo. Segundo, o que estava ali? Disponibilidade. Então, a disponibilidade é toda solicitação que eu fizer de escrita ou leitura ou gravação, precisa receber uma resposta sem falha. Isso é disponibilidade. Eu poder executar as operações sem falha. Isso é disponibilidade. Eu poder executar as operações sem falha. Disponibilidade. Escrita ou leitura, sem falha. E a outra? A outra era a tolerância ao particionamento. Tolerância ao particionamento. Tolerância ao particionamento. Wesley, se você quiser me corrigir em qualquer coisa, pode me falar, tá? Não, vai na fé, é isso mesmo. Toda vez eu tenho dificuldade para falar em português. Tolerância ao particionamento, é esquisito, né? É difícil. E o que quer dizer que isso? Quando eu tenho um sistema tolerante ao particionamento, que ele precisa funcionar, mesmo que falhas de particionamento de rede em especial aconteçam. Sistema rodando em rede, existe uma máxima, né? E aí o que a gente fala cara, se eu tenho e aí não é um problema do CAP se eu tenho sistemas distribuídos hoje o que eu preciso, a máxima distribuídos se eu tenho sistemas distribuídos a minha máxima que eu preciso entender é que sempre haverá particionamento. Por quê? Porque a minha rede vai falhar. A máxima é rede falhará. Se a rede vai falhar, eu preciso escolher no teorema de CAP uma das duas... Não consigo ter as três características, eu preciso ter duas. Então, o que você escolher no teorema de CAP uma das duas, não consigo ter as três características, eu preciso ter duas. Então, o que você escolher? Entre consistência e disponibilidade, entre disponibilidade e tolerância, consistência e tolerância ao particionamento. Sabendo que a rede falhará, você obrigatoriamente vai ter que escolher o C. É o que? Tolerância ao particionamento. O seu sistema distribuído, por padrão, ele vai ter que ser tolerante a essa falha. Se ele vai ser tolerante a falha, o que sobra para a gente arquiteto escolher só esses dois cenários? Ou eu ser consistente ou eu dar disponibilidade. Faz sentido, Wesley? Perfeito. E é aí que o negócio pega, né? Porque vai de cada contexto aí quando você vai escolher cada uma dessas coisas. É. E a gente sabe. Então, eu preciso ter isso porque as minhas... Primeiro, a rede falhará, ela vai romper, ela vai romper, ela não é estável, e aí eu preciso escolher entre um dos dois.