Bom, pessoal, agora, tá? Antes de a gente entrar no estudo de caso do Uber especificamente, tá? Eu quero passar umas dicas aqui pra vocês sobre System Design, tá? System Design é uma técnica, ele parte de princípios de metodologias e normalmente isso é utilizado muito na hora que você tá criando novos projetos. O pessoal que trabalha bastante com arquitetura de solução está super acostumado a fazer esse tipo de coisa, mas também System Design é algo muito importante para quem está querendo entrar principalmente em Big Text, normalmente você tem entrevistas aí focadas em System Design. você tem entrevistas aí focadas em System Design. O grande ponto é que muitas pessoas pensam que sair fazendo System Design é simplesmente sair desenhando e fazer um monte de coisa, tá? E esse aí eu acho que é o principal erro que a galera comete, tá? Então, aqui primeiramente, eu quero trazer para vocês uma estrutura que vocês precisam entender antes de começar a criar qualquer tipo de System Design. E novamente falando, pessoal, é muito importante. Você que já é desenvolvedor sênior, tech lead, arquiteto, assim, ter um conhecimento profundo de System Design é fundamental, porque qualquer projeto grande que você for trabalhar, se você não tiver a ideia básica de um System Design antes de sair fazendo qualquer coisa, simplesmente a chance desse projeto falhar é muito grande. Então o System Design, ele acaba te dando uma visão geral. Ele acaba sendo uma disciplina que faz você passar por algumas etapas que te ajudem a pensar em pontos que eventualmente você não estava indo, legal? Por onde que a gente começa aí então com System Design, tá? Primeiro ponto na hora de começar ali com System Design é referente a algo que normalmente a gente chama de requisitos de engenharia, tá? Requisitos de engenharia, legal? O que que são requisitos de engenharia, tá? Requisitos de engenharia. Legal? O que são requisitos de engenharia? São os requisitos básicos que a gente vai ter para fazer com que o sistema funcione. Legal? Então, basicamente, quando a gente está falando em requisitos de engenharia, a gente está separando esse cara, na realidade, em duas partes, certo? Uma parte são requisitos funcionais, que provavelmente você já deve ter ouvido falar, né? Espero que sim. Bacana, esse é o primeiro tipo de requisito. E o segundo tipo de requisito são os requisitos não funcionais. E muitas vezes as pessoas acabam complicando e não entendendo muito bem a diferença desses caras. Então, nesse momento, eu quero esclarecer isso aqui um pouco para você, só para a gente estar falando a mesma língua. Provavelmente você já conhece, já deve ter ouvido falar, já deva estar trabalhando até com coisas parecidas, mas somente para a gente lembrar. Requisitos funcionais, normalmente, eles trazem para a gente recursos que a nossa aplicação precisa. Quais tipos de recursos? Recursos de utilização. Ou seja, quais são as features, o que o sistema faz, o que o sistema não faz e tudo mais. Basicamente são funcionalidades, são recursos de funcionalidades, de objetivos que vão atender o que o cliente está precisando. Então eu vou dar um exemplo aqui no nosso caso do Uber, por exemplo, do nosso estudo de caso do Uber. Um requisito funcional do Uber, o passageiro ou o cliente, o passageiro barra cliente, ele solicita uma nova corrida a partir de uma localização e um destino que ele quer chegar. Legal? Esse é um tipo de requisito funcional. Ou seja, é algo que o sistema deve satisfazer. Então, isso aí é um ponto importante aí pra você levar em consideração, tá? Requisito funcional. É uma das funcionalidades. É um caso de uso claro do que o sistema, ele vai fazer. Bacana? Agora, a gente tem a outra parte, que são os requisitos não funcionais. Esses requisitos funcionais, normalmente o pessoal costuma brincar que tudo em inglês que termina com ability, normalmente tem a ver com requisitos não funcionais. Por exemplo, liability, scalability, tudo que tem a ver com fazer com que o sistema fique no ar atendendo claros parâmetros, isso aí acaba entrando como requisito não funcional, vou dar um exemplo o sistema ele tem que ter uma baixa latência isso é um requisito não funcional mas normalmente aqui a questão é o que que ter uma baixa latência. Ok? Isso é um requisito não funcional. Mas normalmente aqui a questão é o que é baixa latência no contexto desse projeto? Tá? Então aqui é um grande ponto que você tem que levar em consideração. Inclusive, toda vez que um dia você cair pra fazer uma entrevista, alguma coisa, alguém chegar e falar, baixa latência. Ah, ok, mas pra você, o que é baixa latência? O que você tá esperando em relação a isso? Aí, por exemplo, a gente tem a parte aqui de disponibilidade do sistema. Como que esse sistema ele vai ficar disponível? Ou seja, availability, por exemplo. Como que vai ser a disponibilidade do sistema? Como é que é o SLA desse cara aqui? Aí a gente tem outras questões, por exemplo, eu tenho disponibilidade versus consistência. Às vezes eu quero, tem toda a história do teorema CAP e tudo mais, mas tem momentos que eu quero ter alta consistência e eventualmente eu vou ter baixa disponibilidade porque eu não consigo ter os dois ao mesmo tempo então dependendo do sistema eu posso falar olha, essa parte do sistema eu exijo que tenha consistência essa outra parte do sistema eu exijo que tenha consistência. Essa outra parte do sistema eu exijo que tenha disponibilidade. Então são coisas que você pode acabar trabalhando em relação a tudo isso. Então quando a gente está falando em requisitos não funcionais, a gente está focando tudo que tem a ver com performance, utilização de recursos computacionais, disponibilidade de sistemas, SLA, SLOs, basicamente tudo que você acaba precisando. Por exemplo, replicação dos dados, utilização, por exemplo, de multi-CDNs para que o usuário tenha acesso mais próximo ao conteúdo dele, ao local onde ele está. Talvez isso seja uma forma, por exemplo, de baixar a latência. Então, tudo que a gente acaba tendo de disponibilidade, segurança, latência, consistência, organização dos dados, todos esses tipos de coisa normalmente são requisitos não funcionais. São caras que funcionam por trás dos panos, né? E que mantém o nível de qualidade, quando eu falo qualidade é o cliente que estiver acessando de um lugar ou de outro, etc, que eles acabam tendo a mesma experiência por conta desses requisitos não funcionais. Legal? Então, esses caras aqui são pontos importantes. E, normalmente, quando você vai entrar num processo de System Design, você tem que ter isso de uma forma muito clara. Se você estiver numa entrevista de System Design se você estiver querendo desenvolver o System Design da sua empresa ou qualquer coisa desse tipo você começa pelos requisitos de engenharia sem esses requisitos claramente você não consegue dar nenhum passo no System Design porque você não tem clareza do que tem que ser desenvolvido e como tudo isso vai ser mantido, beleza? No próximo vídeo, a gente vai seguir para um outro ponto importante aí, que vale a pena também levar em consideração, e faz parte, vamos dizer aí, de uma metodologia de System Design, beleza? Então, vamos nessa no próximo vídeo.