Bom pessoal, chegou a grande hora aqui, tá? A partir desse vídeo vai ser basicamente a sua lição de casa pra que esse estudo de caso ele comece a fazer sentido pra você porque no dia do evento que a gente vai fazer via Zoom você já tenha pelo menos o esboço disso que a gente trabalhou você vai aproveitar muito mais a sessão e vai poder comparar a sua versão com a de outros colegas e com a versão que eu também vou apresentar nesse System Design. E para isso, para você começar isso aí, eu fiz agora aqui os nossos requisitos de engenharia e a partir deles eu quero que você comece a ir a trabalhar no seu System Design. Legal? Então é o seguinte, requisitos de engenharia. Então primeiramente requisitos funcionais. Vamos lá, o passageiro solicita uma nova corrida a partir de uma localização, de um destino e como resultado obtém o valor da corrida. O passageiro pode solicitar o início da corrida a partir da solicitação anterior onde ele já possui o valor. O passageiro pode solicitar o início da corrida a partir da solicitação anterior, onde ele já possui o valor. O motorista vai poder receber a solicitação da corrida e aceitar ou não. Se aceitar, ele vai buscar o passageiro na localização inicial e deixar o passageiro no destino final. Se não aceitar, a corrida vai ser apresentada para outro motorista, caso esteja na região. Não vamos cobrir nesse caso, tá? Nem pense em querer colocar qualquer coisa parecida no sistema. A gente não vai fazer avaliação do driver ou do passageiro, se um teve 5 estrelas, 4 estrelas, a gente não vai falar se é UberX, se é UberComfort, a gente não vai fazer nenhum tipo de recurso que fuja do escopo básico daqueles três requisitos que a gente colocou ali. Por exemplo, o passageiro quer mudar a rota no meio do caminho e fazer o recálculo do preço. Ou eu vou dividir o valor da passagem com mais de um passageiro. Nada disso. Focar sempre naqueles três pontos ali que a gente colocou. Aí a gente tem aqui requisitos não funcionais, tá? Então, basicamente, baixa latência pra localizar os motoristas na região. Significa que se demorar mais que dois minutos, a solicitação é cancelada. Então, eu tô dando uma chance aí de dois minutos. Então, o cara vai pedir a solicitação, vai ficar procurando os motoristas ali, fazendo milhares de cálculos complexos, geolocalização, área do cliente e tudo mais. E daí se demorar mais que dois minutos, a corrida é cancelada porque não achou nenhum motorista. E aí a gente tem parte de disponibilidade e consistência. Por exemplo, eu posso ficar disponível para o processo de visualização no mapa no momento que eu tô navegando pelo app, tá? Então, imagina que eu tô navegando, já tô lá com o motorista e aí, de repente, fica um pouco indisponível a localização por algum tempo, mas depois esse negócio volta, tá? Agora, pra parte de consistência, não tem erro. Por exemplo, eu quero garantir que o motorista não aceite duas corridas ao mesmo tempo. Isso é um problema de concorrência grave. Então, eu quero garantir mais consistência nessa parte para evitar que o motorista pegue mais de uma corrida ao mesmo tempo. Mas, eventualmente, eu posso ter sistemas que, apesar de críticos, se ele ficar indisponível por algum tempo, ele não vai afetar tudo de uma vez ali no sistema e não vai necessariamente prejudicar fazendo com que o motorista não consiga entregar o cliente no final o passageiro no final outra coisa, eu preciso que vocês definam algumas métricas que vocês consideram importantes pra garantir disponibilidade do sistema mesmo. Ou seja, dados em tempo real da quantidade de solicitações que eu tô recebendo, recursos computacionais, latência, tá? Então, esses tipos de coisa, eu gostaria que você pensasse em quais são esses dados que você acredita que são importantes pra conseguir ter um pouco mais de clareza do que tá acontecendo naquele sistema. Tá? O sistema ele também deve trabalhar, na maioria das vezes, de forma assíncrona pra garantir mais resiliência e também economizar mais recursos computacionais. Então aqui é uma dica que eu tô dando aqui que talvez trabalhar com filas ou coisas desse tipo, em algumas situações, vão fazer sentido. Legal? Agora, o que a gente não vai cobrir em requisitos não funcionais? Observabilidade completa. Eu quero organizar logs, tracing, tá? Eu quero apenas métricas básicas. Não quero alarme, não quero nada disso. Processo da entrega do software, infraestrutura eu vou jogar isso no Kubernetes na AWS deu algum problema como é que eu vou fazer com que esse sistema tenha self healing pra ele conseguir voltar no ar e depois sincronizar não quero nada disso galera então somente pra você tentar manter ao máximo esse escopo, porque somente isso que eu acabei de passar pra você já é coisa pra caramba, tá? Então não vá pirar colocando um monte de coisa a mais que o sistema não precisa. Fique sempre focado nesses requisitos que eu acabei de colocar, beleza? Agora, quais são os próximos passos agora aqui, pessoal? Eu vou deixar todo esse material disponível aqui pra você e eu quero que você faça o quanto antes, tá? Esse system design. Vá rabiscando, vá tudo isso, porque no dia do evento, isso vai definir o quanto você vai conseguir aproveitar do evento ou não. Lembra? A gente vai estar no Zoom, cara a cara, eu vou estar conversando com você, interagindo com você, vocês vão trabalhar em grupo, você vai conseguir trocar informação com outros alunos, vai fazer networking, tem muita coisa bacana que vai acontecer aí na Full Cycle Tech Week for Seniors. Então, tente ao máximo, porque isso aqui é um desafio legal e eu acho que se você fizer, aí já vai começar a desbloquear bastante coisa. E se você já está acostumado com System Design, eu acho que é mais um desafio aí para você trabalhar. Fechou? Então, está aí o nosso desafio claro aqui para você. Espero que você tenha gostado e que esteja empolgado aí com a nossa semana da Full Cycle Tech Week e a gente se vê aí nos próximos capítulos que a gente vai disponibilizar em relação aos outros cases e tudo mais. Um abraço aí pra vocês.