Bom, pessoal, e chegou a hora aqui que eu quero explicar para vocês o desafio que nós vamos realizar aí durante todo esse processo. E o nosso desafio vai ser fazer o System Design do Instagram. Então, o nosso objetivo aqui é projetar um sistema que vai atender os seguintes requisitos de engenharia, detalhando o que será abordado e o que estará fora do escopo. Então, primeira coisa que eu queria deixar claro aqui para vocês, sempre, mas sempre foquem no que está no escopo do projeto, não fiquem pensando em pontos mirabolantes que estejam fora daquilo que eu estou trazendo aqui para vocês, legal? Então vamos lá. Requisitos de engenharia, tá? Então, normalmente a gente vai separar isso por requisitos funcionais e não funcionais. Então, nesse caso aqui, nós temos como requisitos funcionais o seguinte. O usuário vai poder criar novos posts com a possibilidade de fazer upload de imagens e vídeos. Basicamente, você está lá no Instagram, eu posso publicar uma imagem, eu posso publicar um vídeo. Isso aí. O usuário vai poder seguir outros usuários e também ser seguido. Então, a coisa mais comum do mundo de uma rede social. Eu vou lá, dou um follow em alguém e tem pessoas que podem ali dar um follow em mim também. Bacana? Outro ponto de requisito funcional. O usuário terá acesso ao feed com posts dos usuários que ele está seguindo. Então, toda vez que eu abrir meu Instagram, eu vou ter o meu feed e esse meu feed vai trazer os posts com os vídeos e etc. dos usuários que eu estou seguindo. Agora, pontos extremamente importantes para você não ficar viajando e saindo do escopo do nosso System Design, porque qualquer coisinha a mais que você coloque, pode gerar um nível de complexidade muito maior na hora de você for fazer todos os desenhos e tudo mais, tá? Então, o que que não vai ser abordado? Criação de Stories, gravações de stories do Instagram, eu comentar no feed de outras pessoas, eu fazer uma live ali via Instagram, eu sair fazendo busca, né, de outros usuários, de assuntos e tudo mais, eu fazer o compartilhamento de post de outros usuários, né, mandar um direct pra inbox, listagem de usuários que eu estou seguindo então todos esses tipos de coisa nós não vamos querer no nosso system design então foquem especificamente nesses requisitos funcionais porque são esses requisitos que a gente vai ter que levar em conta, tá? agora a gente tem requisitos também não funcionais e que são importantes você levar em consideração na hora de você projetar o sistema. Então, eu estou colocando aqui que como requisito funcional, não funcional, o nosso sistema vai suportar, por exemplo, 100 milhões de usuários por dia, tá? A gente tem aí sempre também pensando nesse caso, que a disponibilidade é maior que a consistência de dados. Ou seja, eu não vou esperar todos os meus dados estarem 100% consistentes, trabalhando sempre de forma atômica, para então que as pessoas consigam acessar meu sistema. Sistemas de alta escala e de alto uso, normalmente eles vão priorizar a disponibilidade do que necessariamente consistência, tá? Para a exibição do feed, eu estou colocando aqui uma latência menor de 400 milissegundos, ou seja, para o usuário ter uma ótima experiência e que ele não fique ali um, dois segundos esperando para o feed dele carregar, mas eu acredito que uma latência de praticamente meio segundo aí é bem o suficiente, bem ok, pro usuário poder ver o feed dele montado. Um outro ponto importante é que eu preciso ter baixa latência pra exibição das imagens e os vídeos, tá? Porque isso significa mudar completamente a forma e a infraestrutura de como que você vai disponibilizar isso. E o sistema deve operar de forma assíncrona sempre que possível para garantir resiliência e a otimização de recursos. Então, com esses requisitos funcionais, já dá para perceber o tipo de sistema que você vai criar. Por exemplo, se eu fosse trabalhar com um sistema que tivesse mil usuários por dia, provavelmente a infraestrutura, a forma de design, a forma de organização do meu banco de dados, os tipos de tecnologia, soluções, infraestrutura, seriam completamente diferentes de um sistema de 100 milhões de usuários por dia. Então, por isso que os requisitos não funcionais, eles acabam dando pistas bem claras de como que você deve estruturar o seu sistema. Agora, lembrando, em relação ao requisito não funcional, eu não quero que você fique focando em observabilidade, como que vai ser o processo de entrega do software, como que vai ser a infraestrutura, se eu vou usar containers, como que eu vou recuperar o sistema em questões de falha, eu não quero que você fique pensando como que vai ser a interação do usuário na plataforma, a usabilidade, eu não estou pensando em absolutamente nada disso, tá? Eu poderia colocar que o usuário, ele deve utilizar a plataforma de uma forma assim, assado, isso são mais requisitos não funcionais e eu não quero complicar. Então, novamente, esses são os requisitos funcionais, não funcionais, qualquer coisa além disso você pode tentar tirar fora do escopo. Eu sei que apesar de eu estar trazendo todas essas informações, ficam muitas dúvidas ainda na sua cabeça em relação a como montar tudo isso. Então, eu peço que você escreva essas dúvidas que você tem e tente a partir delas, respondê-las da forma que você acha que vai ser o sistema. Ou seja, partindo de um pressuposto que eu vou ter tantos usuários, então eu vou tomar essa decisão. Então, isso é um ponto muito importante. Normalmente, quando a gente está fazendo uma entrevista, por exemplo, de System Design, a gente faz perguntas para o entrevistador para você ter mais informações do sistema. Agora, nesse caso aqui, eu tô dando essas informações. E nesse momento que você tá assistindo esse vídeo, você não pode perguntar pra mim. Por isso que a gente tem o nosso evento, né? Para que a gente esteja face to face, né? E fazendo todas as discussões. Então, mas é importante que você já tenha isso em mente. Maravilha? Tarefas para completar. No final das contas aqui, aqui são os seus entregáveis. O que são os seus entregáveis aí? Eu preciso que você identifique as principais entidades do sistema e as suas relações. A gente já falou sobre isso, sobre entidades. Eu preciso que você estime a capacidade básica do volume de requisições e storage. Galera, fazer planos de capacidade é algo que é realmente, vamos dizer assim, trabalhoso, tem bastante formas de você fazer, a gente aqui na Fullcycle, no nosso programa de MBA, a gente tem aulas fantásticas sobre isso, usando notação científica, fazendo você fazer cálculos muito rápidos e simples para trabalhar. Mas, nesse caso aqui, para agilizar todo o processo, eu não vou fazer grandes agilências no plano de capacidade. Mas eu quero que nas capacidades básicas você pense, por exemplo, quantas requisições eu vou receber? Como é que isso vai funcionar? Quanto de storage, por exemplo, eu vou receber, né? Como é que isso vai funcionar? Quanto de storage, por exemplo, eu vou ter que gastar para conseguir trabalhar com um sistema desse. Nossa, Wesley, mas eu não sei quanto tem um vídeo, não sei quanto que tem uma imagem. Gere o seu pressuposto, baseado nessa estimativa, com uma imagem desse tamanho, com um vídeo daquele tamanho, eu imagino que eu vou ter tanto de storage, por exemplo. Ok? O com vídeo daquele tamanho, eu imagino que eu vou ter tanto de storage, por exemplo. Ok? O outro passo é que você faça a definição do design de API de alto nível com os principais endpoints e os métodos. Então, baseado nesses endpoints e nesses métodos, a gente consegue saber se a gente está conseguindo cumprir aqueles requisitos funcionais que a gente colocou. Depois disso, você vai entregar aí o nosso diagrama visual mesmo, o System Design, mostrando o desenho e a interação ali entre os componentes. Legal? Agora, um ponto importante é, uma vez que você fizer o seu diagrama, o seu System Design mesmo, a dica principal que eu dou para você é faça o seu system design e refletir a implementação dos seus endpoints da API. Quando você fizer isso, você vai ter uma versão simplificada do seu system design. Mas depois eu quero que você comece a se perguntar pontos mais complexos que você podece a se perguntar pontos mais complexos que você pode adicionar no seu System Design para tratar casos específicos, principalmente os casos que fazem com que o nosso System Design consiga corroborar os nossos requisitos não funcionais. Ou seja, qual banco de dados? Qual tipo de banco de dados? Vai precisar utilizar cache? Quais são estratégias de fan-out que eu tenho? Ah, eu vou precisar trabalhar com mensageria? Como é que vai ser processo de upload? Eu vou ter escalabilidade horizontal? Então, pensem sempre em situações, né? Tentando resolver os requisitos não funcionais. Então, a primeira parte do seu system design, pense em como resolver os seus requis não funcionais. Então, a primeira parte do seu System Design, pense em como resolver os seus requisitos funcionais. A segunda parte, pense em como você resolver os seus requisitos não funcionais. E aqui, eu coloquei alguns tópicos somente pra você ter em mente de que você tem que pensar sobre porque pra cumprir esses requisitos não funcionais, provavelmente esses aspectos você tem que levar em conta. Fechou? Então, está aí esse desafio. Espero que você esteja gostando do que você está vendo até agora. E, sem dúvidas, vão ser momentos de grandes aprendizados. Então, até aí os nossos próximos módulos e também os nossos encontros que a gente vai ter para a gente conseguir discutir e ter um bom momento para a gente aprofundar com todo esse tipo de conhecimento. Maravilha? Um grande abraço para você e até mais.