Bom pessoal, agora tá bacana. A gente já sabe as principais funcionalidades, a gente sabe aqui o que vai ajudar as funcionalidades principais e agora o que a gente vai fazer? Nós vamos pensar em requisitos não funcionais. O que são requisitos não funcionais? São requisitos que falam muito mais de atributos de qualidade do sistema do que necessariamente funções que o sistema vai ter. Como assim? Vamos pensar no seguinte. Quais características a gente pode pensar de requisitos não funcionais? Deixa eu até duplicar aqui, somente para ficar bem bonitinho, para a gente conseguir entender. Eu vou colocar características. Quais características eu posso pensar aqui nesse caso para a gente? Bom, primeira coisa, eu quero que o sistema seja rápido. A primeira coisa que o pessoal pensa é, quero que o sistema seja rápido. Isso significa sistema com baixa latência. Sistema com baixa latência Sistema com baixa latência É um sistema rápido Legal? Eu quero um sistema também que ele tenha Alta disponibilidade Ou seja, eu não quero que ele fique fora do ar E ao mesmo tempo Eu quero que esse sistema seja escalável Ou seja, conforme eu vou recebendo mais acessos Mais pessoas vão acessar Eu consigo aumentar o meu hardware, por exemplo Ou seja, conforme eu vou recebendo mais acessos, mais pessoas vão acessar, eu consigo aumentar o meu hardware, por exemplo, para ele conseguir suportar mais acessos. E outra coisa, eu preciso garantir consistência dos dados. Legal? Galera, isso aqui pode parecer óbvio, mas não é Eu estou falando que eu quero um sistema com baixa latência Eu estou falando que eu quero alta disponibilidade Eu estou falando que eu quero aqui escalável E eu quero aqui consistência Eu não sei se em algum momento você já pensou será que é possível eu manter um sistema eu vou até mudar a ordem aqui tá vai ficar melhor e será que eu consigo manter alta disponibilidade com consistência nas minhas informações porque que eu estou falando de consistência aqui? Porque eu estou falando que os dados têm que estar consistentes para eu não vender, por exemplo, mais de um ingresso, o mesmo ingresso para mais de uma pessoa. Legal? Mas, ao mesmo tempo, eu quero garantir alta disponibilidade. E agora vem a minha querida pergunta. Isso é possível? Vamos falar sobre isso, pessoal. a minha querida pergunta. Isso é possível? Hum? Vamos falar sobre isso, pessoal. Existe uma parada, tá? Deixa eu colocar aqui. Eu vou copiar isso aqui que eu acho que vai funcionar se eu copiar esse negócio dessa forma aqui. Pera aí, ó. Existe uma parada que chama de Teorema CAP. Eu não sei se você já ouviu falar no Teorema CAP. Eu não sei se você já ouviu falar no teorema CAP. Bom, a ideia do teorema CAP é o seguinte. Você tem três pilares e você tem que escolher dois deles. Você não consegue ter as três coisas ao mesmo tempo. Legal? Quais são esses três pilares consistência disponibilidade e e e tolerância de partição que significa aqui eu estou preocupado no nosso caso aqui com rede né consistência eu estou querendo manter meus dados consistentes e a disponibilidade eu quero manter disponibilidade então o que ele está falando é o seguinte se eu quero garantir disponibilidade e tolerância aqui de partição significa que eu não consigo garantir consistência se eu quero garantir tolerância de partição e consistência, eu não consigo garantir disponibilidade. E aqui a gente entra numa situação que nós temos que pensar. Porque aqui está muito claro, eu não consigo garantir consistência e disponibilidade. Wesley, o que você quer ver com isso né vamos pensar num exemplo prático vamos lá imagina que você está num caixa el um dinheiro baseado no saldo que aquilo está mostrando na sua conta? Legal? Mas, você é um cara muito esperto. Você e o Pedrinho vão lá, um caixa eletrônico um do lado do outro. Na mesma conta você fala, olha, eu tenho 10 mil reais. E eu vou lá e falo o seguinte, quer dizer, eu tenho mil reais. Eu vou fazer o seguinte, eu vou fazer o saque ao mesmo tempo. Para eu tentar pegar dois mil, legal? Sendo que eu tenho apenas mil ali para mim. O que vai acontecer nesse momento se eu fizer isso? O banco vai falar, eu não consigo disponibilizar para você esse recurso nesse momento. Por que em uma das suas transações ele vai responder isso porque porque ele tem que manter consistência e se ele está mantendo consistência dos dados ele não consegue manter disponibilidade daquela operação pra você legal isso é um ponto importante para você pensar. Agora vamos pensar de uma outra forma aqui para a gente. Vamos imaginar que nós estamos com um sistema de agendamento de passagens de hotel, reservas de hotel. Esses sistemas são muito interessantes, pessoal. Por quê? Porque às vezes eu sou dono de um hotel e eu tenho uma parceria com a Booking, eu tenho uma parceria lá com Hotels.com, eu tenho diversas parcerias. O que pode acontecer em determinado momento? Pode ser que alguém lá no Booking ponto com esteja fazendo uma reserva mas o pessoal do book em ponto com o banco de dados dele o pessoal do roteiro ponto com o banco de dados dele e eu tenho o meu banco de dados o que vai acontecer se alguém ao mesmo tempo duas pessoas ao mesmo tempo em lugares diferentes fizerem a mesma compra, eu posso ter duas opções. Uma opção é ficar indisponível porque eu quero manter a consistência desses dados. Entende o que eu estou dizendo? Porém, o que acontece? Se toda vez que acontecer isso, e tiver múltiplas coisas acontecendo, eu tenho que ficar indisponível, por conta que eu quero manter minha consistência, esse negócio aí não vai funcionar. Então, o que normalmente esses caras fazem? Eles falam o seguinte, eu vou trabalhar com disponibilidade, vou manter alta disponibilidade desses recursos, vou manter alta disponibilidade desses recursos e essa minha consistência ela vai ser eventual o que isso significa? significa que eventualmente por um período de tempo os dados podem ser inconsistentes pode ser que um cara que está comprando o mesmo quarto num hotel A pode ser um outro cara comprando o mesmo quarto num hotel A, pode ser um outro cara comprando o mesmo quarto, e um dos caras vai pegar e o outro vai comprar também, e na hora que chegar no sistema central vai perceber que houve essa duplicidade. E daí, quando houver essa duplicidade, o que você vai fazer? Você vai tomar alguma decisão. Por exemplo, olha fulano, eu sei que você comprou isso aqui e na hora estava disponível, estava mesmo, mas agora eu vou fazer o seguinte, o quarto não está mais disponível. Mas pelo fato de você ter passado por essa situação, eu vou te dar um cupom para você escolher um outro quarto aqui no hotel, por exemplo. Ou num outro hotel. Entende o que eu estou querendo dizer? Existem situações, existem negócios que você não consegue manter consistência e disponibilidade ao mesmo tempo. Eu vou dar um exemplo mais claro ainda para você. Eu acredito que a maioria dos bancos, quando você olha o extrato e olha o saldo, eventualmente aquelas duas informações podem ser diferentes. Por quê? Porque estão em bancos de dados diferentes. E se estão em bancos de dados diferentes, eles podem estar o quê? Inconsistentes. Porém, o banco, a todo momento, quer estar disponível para você consultar seu extrato, ou quer estar disponível para você consultar seu saldo. Então, o que vai acontecer nesse momento? Ele vai fazer o seguinte, eu vou manter a minha disponibilidade e eventualmente eu vou estar inconsistente. Pode ser que o cara viu o saldo dele, eu acabei de fazer uma compra, e quando eu vou olhar no meu saldo ainda não houve alteração do saldo, e daqui um minutinho, 30 segundos, aparece aquela mudança ali no meu saldo. Ou seja, eu escolhi disponibilidade ao invés de consistência. Ok? Nesse nosso caso aqui, a gente quer alta disponibilidade e consistência. Ok, isso é possível, não ao mesmo tempo em determinadas situações. Tá? Por exemplo, se eu quiser falar que eu não vou vender mais um ingresso para mesma pessoa no mesmo lugar quando tentar acontecer essa situação e eu posso ter que ficar indisponível ou e eu posso né tentar sorte vamos dizer assim e ficar inconsistente por algum tempo e eventualmente ter algum problema com o que está acontecendo. Entende como esses tipos de decisão não são necessariamente decisões técnicas. E esse é um dos principais problemas com nós desenvolvedores. principais problemas com nós desenvolvedores. Por quê? Porque desenvolvedor quer tomar decisão técnica como essa, mas no final do dia, galera, essa é uma decisão de negócio. E decisão de negócio é decisão de negócio. Um desenvolvedor que está numa situação como essa ele vai ter que perguntar e falar olha eu tenho essa situação se você quiser alta disponibilidade nesse caso aqui para essa funcionalidade mas ao mesmo tempo mantendo consistência dos dados então eu não vou conseguir o que você prefere entende esses tipos de pergunta galera numa entrevista em qualquer situação podem vir à tona parece algo óbvio mas a gente tem esses tipos de coisa que a gente tem que encarar beleza então isso aí você tem que ficar ligado. São perguntas inocentes, são situações inocentes que mudam completamente. Às vezes eu tenho um banco de dados que está espalhado em diversos nós com sharding, e eu estou recebendo requisições, esses bancos de dados de leitura que eu tenho, por exemplo, ainda não estão sincronizados, então eu estou consistentemente defasado por algum momento, a minha consistência é eventual. tenha dado uma luz aí pra vocês e pra você entender que características de um sistema elas têm que ser muito bem pensadas e você sempre tem que ter clareza do que vai acontecer em cada caso beleza um grande abraço até o nosso próximo vídeo