Mas aí vem o mais básico. O que foi o mais básico na construção do design do sistema distribuído? Eu nunca posso isolar... Vou até escrever aqui. Eu nunca vou isolar... Eu nunca vou isolar... Isso é interessante, isolar recurso de requerimento. O que eu quero dizer com recurso, Fernando? Quais são os recursos que eu tenho no desenvolvimento de um projeto? Wesley, quando a gente está num projeto, aí chega um cliente para você, cara, quero desenvolver um projeto. Que recursos que a gente normalmente pensa? A gente pensa em, para mim, três recursos. Para mim, são fundamentais. Tempo, pessoa e dinheiro. Perfeito. Para mim, o system design tem que levar em consideração o quê? Cara, essas três variáveis também, esses três recursos. Não adianta escrever um design da galáxia que leva daqui à nuvem se eu tenho problema de tempo, se eu tenho problema de dinheiro e se eu tenho problema de pessoas. Então, isso é fundamental. Quantas soluções a gente já não escutou, viu na literatura, escutando falando de grandes arquitetos que começaram soluções super famosas que estão rodando hoje, que começaram o MVP de uma forma que a gente vai até te dar um nome aqui para todo mundo aprender, middle out, buscando o certo da arquitetura para depois fazer uma construção evolutiva. E não, cara, vou vir bottom up, top down, na verdade eu vou buscar o problema central e de lá eu vou expandir a minha arquitetura, meus requisitos de design, para que eles consigam abranger novos recursos. Por quê? Porque o software ele é um filme e não é uma foto. Todo dia, se você conversar com alguém da operação, ele vai ter um requisito novo. Então, eu tenho que pensar no middle out. Como que eu construo um organizador no meu system design que eu possa evoluí-lo sem ter que jogar fora tudo que eu fiz? Tempo? Dinheiro? Faz sentido? Perfeito. Não posso tirar isso da equação. Nenhuma empresa quer jogar dinheiro fora, não quer jogar tempo fora, quer recomeçar. Mas tudo tem em mente essa verdade. O software vai ser um filme. E as restrições a gente já conhece. As restrições eu vi até lá na documentação de vocês lá. Eu achei bem legal e eu até gostaria de contribuir aqui com algumas restrições que eu acho que são relevantes. Uma restrição. Quanto que é o meu custo de downtime? Está previsto? O custo de downtime é a primeira pergunta que eu faço quando alguém chega para mim e fala cara, eu quero construir uma arquitetura da NASA. Mas qual que é o custo de downtime? Quanto custa ficar um segundo parado? Ah, irrelevante. Aí, um final de semana? Ah, irrelevante. Fora do horário comercial aí, relevante é diferente eu tenho um caso eu estou assistindo lá minha série lá no Netflix aí eu vi lá um setup e quero comprar aquele relógio lá do Instagram que só vende aí na gringa Wesley que mostra indicadores, tem um nome, né? Não sei das quantas lá, quantos seguidores você tem, e dá aquele comichão de comprar. Cara, o e-commerce preferido meu não pode estar fora naquele momento, né? Naquele momento não pode, eu quero fazer essa compra. Então o custo de downtime para alguns cenários é muito dinheiro. Outra pergunta que eu sempre faço para os clientes. Qual é a possibilidade de eu suportar o downtime? O que é a possibilidade de suportar o downtime, Fernando? Um é o custo-oportunidade e o outro é eu não operacionalizo naquele horário eu perco dinheiro e no outro eu não tenho operação então é a minha possibilidade de suportar isso cara, eu perdi dado isso é uma restrição? quanto que é o meu custo de perder dados? não sei se todo mundo viu. Todo mundo conhece aquela... Deve ter uma literatura no meu canto ali. É o Engenharia de Confiabilidade do Google. Aquele livro fala de um case do Google que teve um ano que as playlists, 60% do catálogo desapareceu. Teve um incidente e desapareceu. E aí a engenharia de confiabilidade que estava preparada fez ocorrer o recorrido desses dados de forma muito mais rápida do que a gente tinha previsto. Então a gente tinha uma previsão de fazer o curso, esse custo de perda de dados. Isso é muito relevante porque eu vejo que, às vezes, a área de engenharia não faz análise de risco. E a gente, às vezes, com boa prática, até indica para as pessoas fazerem a análise de risco para entender quanto é o custo do meu risco no ano. Te dar uma previsibilidade disso. Isso é uma restrição também que pode noticiar o meu design. Então, esses entes restritivos também são importantes, porque eu perder dados também, às vezes, eu posso perder dados num cache. Cara, qual que é o custo de eu perder o dado num cache? O quanto que isso me impacta na minha solução? Quantas soluções você já não viu? O cara usa uma máquina do Redis, uma máquina para o Redis, e ele não tem nem um sentinel rodando ali no cluster. Porque ele vê que para ele é irrelevante. Para ele, ele perdeu esse dado, pouco faz impacto, porque ele sabe que ele pode ser povoado novamente ao momento em que a máquina, o serviço estiver disponível. Inclusive, você entende isso. Só que isso não é verdade para todos os cenários. Tem casos que você tem que aquecer o cache antes, porque se subir sem esse cache estar aquecido, a aplicação não aguenta e ponto. Então, você tem que aquecer o cache antes. Então, você me traz algo muito relativo ao volume de dado armazenado. Armazenado. Eu atendi um cliente que esse cara é um dos caras que mais faz venda de e-commerce de passagem no Brasil. armazenado. Eu aprendi um cliente que esse cara é um dos caras que mais faz venda de e-commerce de passagem no Brasil. E esse cara, o volume que tinha de dado armazenado em cache era absurdo. Suportava reaquecer para ele, era um impacto. O cache no final era utilizado para eu acelerar a resposta e evitar a leitura do disco, mas era um grande impacto porque os Jasons ali que estavam armazenados em cache, cara, um registro pesava 10 megas. É incrível. É fora de sério. Não, era fora de sério. Mas tudo isso Era tudo isso porque ele tinha dados de cruzamento Imagina, de várias operações De voo no mundo Pra que? Ah, eu vou de São Paulo a Rio de Janeiro Aí Nessa condição, ele trazia vários cenários Hotéis, carros Tristes de passagem, viagens Fotos, blá blá, blá, blá. Era um negócio violento. Então, quantas pessoas não procuram, por exemplo, no final de semana, de São Paulo a Rio de Janeiro? Eu não vou sempre fazer essa consulta nos sistemas também acessórios da minha arquitetura, porque eu também preciso pensar nisso. Eu tenho sistemas que estão fora da minha arquitetura, que também podem ter down times. Então, volume armazenado, para mim, é outro fato relevante. Como eu comentei inicialmente, frequência de leitura e escrita. Eu vi que vocês viram isso. Isso é uma questão super relevante também. A mais básica, número de usuários. também. A mais básica, número de usuários. A gente sempre está atrás disso. Número de usuários e o tempo de resposta. Então, essas restrições que são básicas, elas vão determinar para a gente o tamanho da solução e o tipo de solução que o meu cliente espera, certo? Então, a gente é cobrado, aí existe um outro problema, a gente como arquiteto, engenharia, a gente é cobrado por estimativas, dado tudo isso, alguém chega sempre depois e pergunta, cara, qual que é a estimativa disso? e pergunta, cara, qual que é a estimativa disso? Qual que é a estimativa? Agora que eu sei as verdades, cara, eu sei o que eu tenho, que eu não posso separar esses requerimentos, que eu tenho essas restrições que são restrições básicas, eu quero entender as estimativas. E aí é algo que dói, às vezes, nas pessoas, dar estimativa. E a estimativa, eu já te adianto, ela não precisa ser perfeita. Você está louco? Não precisa ser perfeita. Às vezes a gente gasta tanto tempo tentando buscar uma estimativa que a gente nunca vai alcançar ela. Isso incluso é uma máxima que a gente fala em SRE. A estimativa de 100% é uma falha. Não sei se eu já falei para as pessoas aqui. Já cheguei a falar disso no seu canal, Wesley? Não. Porque é uma falha, não? Porque a estimativa é de buscar o 100% do que o meu usuário quer uma falha. Porque o 100% eu só vou alcançar numa condição, uma condição estática. Quando eu tiver o meu arquilógio numa condição estática, que não tem volatilidade, meus usuários que não tem volatilidade, meus usuários que não tem volatilidade, meu hardware que não escala, cara, ele vai ser 100%. Só nesse cenário ele vai ser 100%. Incluso meu software também, ele é 100% estático quando eu não tenho mudança nele. Por isso que incluso lá o Ben, que é o chefe de arquitetura de SRE do Google, ele até fala no livro, ele fala, cara, 100% é uma falha para tudo, porque a gente não tem espaço para corrigir as coisas, para inovar. E normalmente a gente é cobrado pelo 100%, a gente tem que tomar um cuidado com isso.