O evento de hoje, dessa semana, o nosso foco realmente está em profissionais sêniores, tech leads, para frente. Se eventualmente tiver alguém aqui na sala hoje que não esteja mais ou menos nesse tipo de posição, assim, obviamente, todo mundo é mais do que, como se diz, encorajado e bem-vindo para participar aqui do evento com a gente, tá? Mas a gente vai falar de assuntos que normalmente não fazem parte do momento profissional de quem está iniciando na carreira, tá? Eu só queria deixar isso muito bem claro, porque às vezes a pessoa vai num evento e acaba se sentindo às vezes destimulada, ou fala um monte de coisa que não tem nada a ver, que eu nem uso no dia a dia, ficou mostrando um monte de rabisco na tela e etc. Eu queria ver código, o cara não faz o negócio e não sabe nem programar, entendeu? Então, porque a pegada e os desafios são diferentes conforme a gente vai evoluindo, vai passando o tempo, por isso que eu queria sempre deixar bem claro isso, tá? Então, se alguém tiver que não tá mais ou menos nesse momento profissional, e é só uma questão de tempo, né? O tempo vai passando, né? Uma hora você é júnior, pleno, sênior, tech lead, tech manager, e daí vai, staff principal, independente da posição que você está. Então, o nosso principal ponto aqui é esse hoje. Queria dar boas-vindas, obviamente, agora oficialmente aí para todo mundo. Galera, saiba, assim assim que é um mega prazer de saber que no início de uma semana, né, a gente tem no Zoom, né, quase 800 pessoas aqui querendo aprender, querendo discutir e a ideia é que esse evento ele não seja algo 100% inclusive centrado em mim, né, eu quero obviamente tentar facilitar ao máximo, trazer as minhas opiniões, tentar puxar e pilotar as coisas, mas eu quero que grande parte do que a gente faça, que vocês possam construir aí ao mesmo tempo. Então, o nosso objetivo é fazer o quê? A gente vai ter três dias principais, entre aspas, tá? Esse nosso primeiro dia hoje a gente vai falar especificamente de System Design. Eu não sei se todo mundo tá habituado ou já teve que fazer um System Design, se já teve que participar de alguma entrevista que você teve que passar numa entrevista de System Design, ou se o System Design foi uma ferramenta, assim, extremamente importante para você arquitetar e trabalhar com grandes aplicações. Independente se você já teve a experiência de trabalhar ali de forma geral com o System Design. Alguém está compartilhando tela aqui, galera? Por favor, deixe só eu compartilhar uma vez de cada, tá? Então, o... O pessoal está ansioso aí. O pessoal está ansioso, já está querendo mostrar o projeto aí. Então, a nossa ideia é a gente conseguir falar de System Design, mas o mais importante de falar do System Design é a gente explorar alguns pontos assim que realmente acabam ficando com uma pegadinha ou numa entrevista ou dentro da própria empresa tá, então esse é o primeiro ponto e eu queria pegar um exemplo de um domínio de forma geral que todo mundo conhece né, que nesse caso a gente vai trabalhar com um estudo de caso focado na Uber e novamente, eu também não sou um especialista em Uber, eu não tenho ideia de detalhes de implementação e de como eles trabalham em muitas coisas lá existem algumas coisas que são alguns cases que eles já mostraram algumas coisas que obviamente eu dei uma estudada pra chegar aqui e também não passar muita vergonha mas a grande pegada é que a ideia é a gente ter um case e em cima desse case dia a dia a gente vai passar por alguns pontos que eu acredito que são importantes e que isso vai servir pra qualquer tipo de sistema e solução que a gente vai fazer tá, então o nosso principal foco hoje é System Design, entender como é que funciona a estrutura de um System Design. Eu espero que muitos de vocês tenham tido a oportunidade de ter entrado na nossa plataforma da Full Cycle, tá? Onde a gente colocou algumas aulas meio prévias ali somente pra tentar dar uma nivelada. Se você não teve acesso ainda, saiba que provavelmente no seu e-mail, em algum lugar você tem um link que você consegue logar. É a mesma plataforma que os nossos alunos estudam, a gente liberou um módulo lá específico desse evento. Um ponto importante também é que, então, nesse primeiro dia, a gente vai falar especificamente sobre System Design, a gente vai falar sobre Design de API, a gente vai entender um pouco alguns aspectos. No segundo dia, nós vamos focar muito em comunicação entre sistemas e, a partir daí, a gente vai ter que modificar o System Design que a gente vai fazer hoje, pensando muito mais em comunicação. Porque a forma como você trabalha com comunicação entre sistemas vai conseguir determinar diretamente o quanto que esse sistema vai conseguir escalar. Então, esse é o primeiro ponto. O terceiro dia, a gente vai falar muito sobre a gente vai falar sobre assuntos como DevOps e SRE, mas principalmente a gente vai falar muito sobre a gente vai falar sobre assuntos como DevOps e SRE, mas principalmente a gente vai falar muito sobre confiabilidade dos sistemas, que eu acho que é o grande ponto principal que a gente quer garantir no dia a dia que as coisas funcionem sem ter que ficar culpando alguém. Eu acho que o maior problema que muitas empresas têm e etc, é sempre ter o culpado. A culpa foi dele que fez o update sem o R no banco de dados. Mas o banco de dados tinha alguma trava, algum processo para evitar esse tipo de problema. Então, a gente vai pegar muito em alguns aspectos. A gente vai falar de diversas métricas, diversos pontos que são importantes para qualquer empresa grande. Tudo que a gente está falando aqui, pessoal, inclusive, é pensando sempre num sistema que vai ter alta concorrência, múltiplos acessos, que vão precisar utilizar tecnologias, sistemas, bancos de dados diferentes, e não necessariamente a gente vai ficar focando no sistema que vai ter 10 usuários simultâneos, né? Então muda muito a perspectiva da forma como que a gente tem que acabar colocando. Eu falei logo no início que a gente ia fazer uma entrega a mais na quinta-feira. O que é essa entrega a mais? Uma das coisas que eu percebo no dia a dia, tá? É que muita gente tem dúvidas técnicas de todos os aspectos e tem muitas pessoas que às vezes estão um pouco struggling ou passando por alguma situação na carreira onde ela não consegue crescer na carreira, ou ela tá desanimada, ou acha que ela não está aprendendo o suficiente, ou precisa de alguma dica. Então, o que a gente vai fazer é, na quinta-feira, fazer uma sessão realmente de mentoria. Eu estou tentando trazer uma pessoa de peso aqui também para ajudar a participar nessa sessão de mentoria, mas vai ser uma sessão livre de mentoria, onde vocês vão poder... Óbvio, a gente faz uma fila aqui, a gente faz uma fila aqui, a gente taca as mãozinhas de vocês no RabbitMQ, e daí a gente vai consumindo, first in, first out, e a gente vai batendo esse papo, e o que eu acho mais legal de sessões de mentoria, é que elas, como que eu posso dizer, mesmo você não fazendo a sua pergunta, é incrível o quanto você aprende com a pergunta das outras pessoas, porque às vezes é exatamente o problema que você está passando, tá? Então pergunta das outras pessoas, porque às vezes é exatamente o problema que você tá passando tá, então eu acho aí que essa é a grande sacada aí, tá então pessoal como é que vai funcionar então a dinâmica de hoje, tá, eu acho que deu pra vocês entenderem, se vocês quiserem participar na sessão de quinta-feira da mentoria, preciso que vocês participem de segunda, terça e quarta, porque a mentoria normalmente é muita gente falando, né, então não dá pra dar atenção pra todo mundo, então a gente acredita que vai ter menos gente, menos pessoas, então a gente consegue manter a qualidade da mentoria com um grupo que vai acabar ficando menor de uma forma ou de outra, tá? Então isso aí é importante pra vocês saberem. Eu vou compartilhar aqui a minha tela. E na tela que eu vou compartilhar, tem muito do que eu passei na nossa plataforma. Depois eu vou até navegar aqui na plataforma para vocês verem onde que tá disponibilizado o conteúdo, tá? Deixa eu colocar só pra garantir que eu tô compartilhando a tela certa, tá? Entire screen. Ô Wesley, antes de começar o conteúdo em si, você vai dar oportunidade pra gente tirar dúvidas sobre o que você pediu pra que fosse feito nos módulos? Com certeza, eu vou mostrar o caso, aí eu vou dar alguns minutos pra quem tiver dúvida, fazer perguntas em cima desse System Design e eu espero que sejam perguntas realmente boas porque são através dessas perguntas que vão ajudar vocês a resolverem um monte de problema, né? A grande sacada do System Design é você conseguir perguntar, tá? Então, acho que esse aí, eu acho que é o principal ponto, tá? Galera, só pra vocês saberem, tá? Se vocês acessarem plataforma.fullcycle.com.br vocês vão ir logar, e se vocês não souberem a senha, a gente mandou pra vocês uma senha tá, e se vocês não souberem, vocês vão e clica esqueci minha senha, bota o seu e-mail, vocês sabem como é que funciona essa parada né, os caras tem 10 anos de TI se não souber recuperar a senha eu vou chorar tá, então basicamente, quando vocês entrarem, se você não for aluno nosso, inclusive... A gente abre chamada pra infra. Abre uma chamada pra TI. E daí faz uma gemude pra melhorar a parada. O lance é o seguinte, se você não for nosso aluno, vai aparecer somente esse cara aqui pra você. Se você for, vai aparecer os outros cursos, mas é esse cara aqui, ó. O Psychotech Week for Seniors. Quando vocês clicarem aqui, vai ter esse módulo. Deixa eu já abrir aqui, ó. Já vai estar nesse módulo e se vocês olharem, tem três capítulos aqui, tá? Tem estudo de caso Uber, tem comunicação e resiliência e tem DevOps SRE. Esses são os três temas principais que a gente vai falar um em cada dia, além da sessão de mentoria na quinta-feira. Nessa sessão de estudo de caso do Uber, eu trago alguns conceitos, eu vou repassar esses conceitos hoje aqui, mas eu recomendo que vocês entrem na plataforma, assistam, são vídeos bem curtos, tá, galera? Eu não quis pegar, fazer algo muito maçante, porque a gente vai passar um bom tempo aqui, mas vale a pena a gente colocar. O que é importante nesse cara aqui, é essa tela aqui. Essa tela, basicamente, o que ela traz pra gente é os requisitos que a gente vai ter para fazer esse System Design. E aqui são as tarefas que a gente vai ter que fazer durante essa semana e que eu espero que vocês já tenham feito alguma coisa ou já pelo menos tenham pensado em alguma coisa desse tipo. Espero que vocês já estejam aí já nessa vibe, beleza? Então, essa que é a nossa ideia principal. Eu vou falar rapidamente sobre esse desafio e daí eu vou trazer alguns aspectos aqui para a gente conseguir entender como é que funciona. Pessoal, o ponto principal aqui é o seguinte. Primeira coisa, eu vou falar uma coisa que é super básica, mas eu vejo um monte de gente acabando se confundindo com isso, tá? System Design é diferente de Design System, tá? Design System tem algo muito mais a ver de componentização pra parte de comunicação pra parte principalmente de front-end pra reutilização de componentes e padronização, tá o system design é como que você realmente vai pensar de forma principalmente a mais alto nível como que um sistema ele é como ele vai ser desenhado tá, então esse aí é um ponto aí principal. Então, o que que acontece? Pra que a gente pudesse não ficar viajando na maionese e ficasse fazendo algo totalmente surreal, com um trilhão de funcionalidade aí do Uber, o nosso principal ponto aqui é setar alguns requisitos. E essa, pessoal, é a primeira parte de qualquer system design que vocês forem encontrar. Nem que não seja falado formalmente para você. Principalmente se você está querendo entrar em Big Techs, a pessoa vai começar a falar um problema ou alguma coisa assim para você, e daí na hora que ela começa a explicar e trabalhar com esse problema, normalmente o que ela está falando é o que a gente chama de requisitos de engenharia então esses requisitos de engenharia, normalmente eles são separados em duas áreas requisitos funcionais e requisitos de engenharia normalmente eles são separados em duas áreas requisitos funcionais e requisitos não funcionais, eu acredito que na maioria, a maioria das pessoas aqui já devam saber meio que a diferença de requisito funcional ou não funcional de qualquer forma eu vou só dar uma passada por cima pra garantir que tá todo mundo na mesma página beleza? Então forma eu vou só dar uma passada por cima pra garantir que tá todo mundo na mesma página, beleza? Então, negócio é o seguinte, pessoal. Requisito funcional. É muito claro. É a função. É o que o sistema tem que fazer. Caso do Uber aqui. O passageiro, ele pode solicitar uma nova corrida, informando uma localização de origem e destino, obtendo o valor estimado da corrida, informando uma localização de origem e destino, obtendo o valor estimado da corrida. O passageiro ele pode, o passageiro pode confirmar o início da corrida com base na solicitação anterior, onde ele já possui o quê? O valor, né? Então, na realidade, o que acontece é quando você solicita uma corrida pro Uber, o que vai acontecer no final das contas? O que vai acontecer é... O que vai acontecer é... Saber o trajeto e o cálculo de quanto foi a corrida. O principal ponto é, a primeira chamada que você faz para o Uber é um orçamento. A real é essa. Entendeu? É um orçamento. Ele provavelmente vai falar quanto tempo o cara demora pra chegar e ele vai falar quanto que vai custar. É ali que é o famoso orçamento. É a parte de fair. Tá? Agora, o motorista, ele vai receber a solicitação de corrida e optar por aceitar ou não, né? Se ele aceitar, ele vai buscar o passageiro na localização de origem, vai levar até o destino se recusar, a corrida vai ser disponibilizada pra outro motorista na mesma região o que que a gente não vai abordar e quando eu tô falando que a gente não vai abordar é que na hora que a gente, vocês entrarem na sala, na hora que vocês forem começar a fazer, eu quero que vocês nem passem pela cabeça de vocês, pensar em qualquer tipo dessas complexidades. Isso vai ser completamente fora do escopo, tá? Então, o que não vai ser abordado? Se vai avaliar o motorista, se é cinco estrelas, a qualidade do negócio, se é UberX, se é UberXL, se é UberComfort e etc. Ah, e se o Uber for passar e dividir com outra pessoa para dividir a conta, entendeu? Então, ah, o cara no meio do caminho resolveu passar na casa da sogra, e daí tente cobrar mais. Cara, isso aí é totalmente fora do escopo. Então a gente tem três requisitos importantes aqui de engenharia. É somente em cima desses três caras que a gente vai trabalhar. E quando a gente fala que é somente, é coisa pra caramba na realidade. É muita coisa. É simples. Pedir pro meu sobrinho fazer um app. Faz o seguinte, você pede, daí o cara responde, aceita ou não aceita, é tudo muito simples. É mais ou menos isso que a gente vai fazer aqui em três dias. Em três dias dá para fazer isso. A gente vai fazer até um bot de AI para ele fazer isso para a gente, inclusive. Imagina que do ponto de vista de system design isso não vai mudar tanto, mais a notificação, mas eu acho que talvez valha colocar que não tem cancelamento aqui também, né? Ah, sim, não tem cancelamento aqui também, né? Ah, sim, não tem cancelamento. Importante colocar. Galera, o que vocês têm que focar claramente aqui é passageiro pode solicitar uma corrida. Passageiro pode confirmar a corrida. Motorista pode receber a solicitação, aceitar para entregar o cara. É isso que a gente vai falar nesses três dias. São três bullet points, basicamente. Tá? Agora, a gente tem aqui requisitos não funcionais. Pra deixar cada vez mais transparente, principalmente quando a gente tá falando em inglês, tá? Normalmente, tudo que termina com ility é requisito não funcional. Aveability, a liability, a... Cara, tem um trilhão de abilities no meio, tá? Normalmente o requisito não funcional são requisitos que ele tem a ver com a garantia de funcionamento e o comportamento do sistema. Ele tem muito mais a ver com o que fazer com que o sistema ele esteja disponibilizado da forma mais ideal possível ali pra pessoa. Então, esses requisitos, eles mudam completamente como é que o system design é feito. Por exemplo, eu posso fazer um sistema design de um sistema que vai acessar 100 pessoas vão usar. E eu posso ter o mesmo sistema, com os mesmos requisitos de engenharia que um milhão de pessoas vão acessar. Todo mundo aí já de cara tem certeza que os sistemas vão... Então é o seguinte, galera. Então tudo que tem a ver com comportamento e capacidades do sistema, a gente está falando sobre requisito não funcional. Então é o seguinte, o sistema deve localizar motoristas na região em menos de dois minutos. Caso contrário, a solicitação deve ser cancelada. Isso é um requisito de negócio, mas acaba tendo também um pouco de requisito de comportamento de como o sistema vai trabalhar. E uma coisa importante, tá, pessoal? Requisito funcional e não funcional, eles estão 100% ligados a todos os momentos. Então isso é um ponto importante. Por exemplo, o sistema, ele deve permitir que o passageiro acompanhe a movimentação do motorista em tempo real no mapa, mesmo que algumas atualizações possam apresentar um leve atraso para garantir disponibilidade. O que isso aqui quer dizer? Se você pensar bem, em relação a esse requisito aqui, parte dele eu poderia jogar ele aqui para cima como funcional. Vocês concordam comigo? Que é uma funcionalidade de um cara poder acompanhar o outro. Eu tive exatamente essa ideia quando eu vi essa parte do texto. Você quer um requisito funcional? Pode entrar com certeza como requisito funcional. Agora, tem um ponto importante aqui. O que pega no requisito não funcional aqui é essa parte, é essa provocação que eu queria trazer para vocês. Mesmo que algumas atualizações possam apresentar um leve atraso para garantir disponibilidade. Você consegue, a partir daí você vê o comportamento. O que eu estou dizendo aqui no final das coisas é, eu não vou garantir altíssima disponibilidade com esse tipo de recurso. Por quê? Mas é... Wesley... Wesley... Vai na fé, pode perguntar. Aí entra muito o que eu já vi em outra imersão com você tempo real, né? o que é tempo real, né? então, a gente vai cair nisso principalmente na parte de amanhã, quando a gente vai falar sobre comunicação, tá? mas, perfeito? mas o ponto principal aqui disso tá no não funcional isso aqui com certeza pode jogar pra cima eu pedi pra galera jogar pra cima, mas eu acho que o pessoal não atualizou, eu ia repetir essa linha aqui, mas o ponto principal do não funcional aqui é essa é a dica, tá que é o que, mesmo que algumas atualizações possam apresentar um leve atraso, para garantir disponibilidade alguém tem ideia o porquê que um leve atraso pode permitir a garantia de disponibilidade? Alguém consegue fazer essa reflexão? Eu vou falar. Nem mente de rico, é isso que o servidor suporta. Alguém? Porque nesse atraso aí o motorista pode ser alocado em outra corrida, né? Eu vou ter sempre a resposta pro usuário, mesmo que o servidor não tenha me respondido. Você pode usar o mensageirinho com resiliência ou não. Quem falou de teorema CAP aí? Foi o Victor. O Victor é o hacker, né? Ou não? Não. Cara, ele tem a ver com o lance de O Vitor é o hacker, né? Ou não? Não. Não é o hacker, não. O que eu falei? O Wesley tem a ver com o lance de resiliência das mensagens? Se você vai usar o Kafka ou o ReptMQ? Não, esse caso tem a ver com o Teorema Cap. Basicamente, o que a gente tem... Teorema Cap participa de três partes, mas o maior ponto aqui é o seguinte. Para qualquer sistema, se você quer garantir alta disponibilidade, você não consegue garantir consistência. Correto. Se você quer garantir consistência, você não consegue garantir alta disponibilidade. Vou dar um exemplo muito simples. Um caixa eletrônico. Caixa eletrônico tem que ter alta disponibilidade? Tem. Mas o que é mais importante? Consistência. Consistência. Só para deixar o cara sacar mais. Eu prefiro que o meu caixa eletrônico esteja fora do ar do que deixar alguém ter o saldo em válido ou sacar mais dinheiro. Uma situação que ocorre muito, por exemplo, quando eu vou pagar alguma coisa com o banco e eu estou sem o pacote de dados, que às vezes eu esqueço de habilitar, eu consigo pagar. Ele não deixa eu ficar sem pagar. Aí quando eu chego em casa ou quando eu lembro de ligar o pacote de dados, por exemplo, que ele faz a transação. Ele está usando uma fila. Com certeza. Ele está armazenando o local. Isso é um conceito de consistência eventual. Mas aí que está. Aí é consistência eventual. Mas o grande ponto aí é o seguinte. Se você quer garantir naquele momento consistência, em algum momento você vai abrir mão da disponibilidade. Porque se por algum momento o seu sistema for inconsistente, se o seu sistema por algum momento não estiver consistente, ele não pode estar disponível. Essa que é a grande questão. Agora, num caso de um Uber da vida, em qualquer sistema grande que a gente trabalha, existem momentos ou partes do sistema, e eu acho que essa que é a grande sacada quando você vai arquitetar qualquer aplicação, é quais partes do sistema que para mim faz sentido ter alta disponibilidade e qual parte dos sistemas, para mim, faz sentido ter consistência? Por exemplo, aqui, no caso do Uber. Mesmo que algumas atualizações possam apresentar um leve atraso. O que é isso? O que eu estou dizendo aqui? Que esses dados... Eu posso perder alguma posição, mas isso não vai interferir, porque eu posso recuperar depois. Eu tô mantendo alta disponibilidade, mas eu não tô sendo consistente aqui. Exato. Eu tô perdendo dados, mas eu tô deixando disponível o sistema. Agora, né? Olha só. Pra garantir consistência, o sistema deve evitar que um motorista aceite mais de uma corrida ao mesmo tempo, mesmo que isso signifique uma indisponibilidade temporária em casos específicos. Porque aqui é diferente. Eu prefiro ficar indisponível do que fazer um motorista ter que aceitar dois passageiros ao mesmo tempo que vão pra lugares diferentes. Você entende? Aqui é o inverso. Eu posso deixar o cara perder uma posição ou outra, ou eu ficar, sei lá, 20 segundos, sei lá, de acordo com o que está acontecendo, sem saber exatamente aonde que o motorista está. Mas, eu jamais vou poder permitir que o motorista aceite duas corridas. Se eu tiver problema de consistências na corrida, eu prefiro ficar indisponível então essa que é a grande sacada quando a gente está falando em CAP é consistência disponibilidade e partição mas vamos nessa outra coisa importante aqui como requisito não funcional e a gente vai falar disso também é métricas importantes devem ser definidas para monitorar a disponibilidade como tempo de resposta uso de recursos computacionais latência e taxa de falhas o sistema deve operar de forma assíncrona sempre que possível para garantir resiliência e otimização de recursos a gente também vai falar bastante disso amanhã principalmente o que que não é para ser abordado em relação a requisito não funcional? Implementar a observabilidade. Como é que vai ser a padronização de logs? Como é que vai ser a padronização de tracings? E etc. Como é que vai ser o processo de entrega do software, que ele vai passar em todos os tipos de pipeline, etc. Como é que vai ser a infraestrutura, quantos clusters Kubernetes eu vou utilizar, entendeu? Como é que eu vou fazer um processo de recuperação de falhas, um relatório pós-morte? Eu não quero nada disso. A única coisa que eu quero que vocês tenham em mente aí é que existem alguns pontos que já dão dicas claras aqui para a gente, que partes dos sistemas, ele vai ter que ter alta disponibilidade, e parte do sistema vai ter que ter uma alta consistência. Então, esse é um ponto importante. Então, o lance é o seguinte, galera. Quais são algumas tarefas que a gente vai trabalhar? Uma delas eu vou pular hoje, porque daria para fazer uma aula... Daria para fazer duas horas só essa tarefa. Mas eu vou trazer alguns materiais para vocês olharem. No nosso MBA tem uma parte que é só disso, que é só cálculo, inclusive. Mas que é a parte de plano de capacidade aqui pra gente. Mas o ponto principal nosso aqui, a gente tem que entender as entidades e as suas relações. A gente vai falar sobre isso. Como que a gente faz o design da API de alto nível, os principais endpoints e métodos. Como que a gente cria o diagrama visual com as interações dos componentes do sistema e aí é a parte que é a mais complexa que acaba sendo que é quando o nível desce o que que é isso? possibilidades de perguntas complexas tá? e isso aí eu vou deixar sempre como dica em entrevista tá galera? você vai participar de uma entrevista de System Design, você vai falar, ah, e aqui eu vou usar o Kafka. Pronto, você falou a palavra Kafka. Aí o entrevistador vai falar, ah, legal, você gosta de Kafka? Gosto. Como que o Kafka funciona mesmo? Ah, o Kafka trabalha com partições de forma distribuída. Ah, legal, mas como que ele mantém alta disponibilidade? Como que eu faço pra eu não ter hot partition? Como que eu faço pra garantir a parte de segurança? E se eu quiser trabalhar com streams, como é que ele funciona? Você já usou o ksqlDB? Como que você consegue fazer os serviços gerenciados? Você usa bastante as coisas da Confluent, já usou algum outro serviço? E, serviços gerenciados, você usa bastante as coisas da Confluent, já usou algum outro serviço e cara, aí meu amigo, se você não entende de Kafka e falou a palavrinha a cara cai no chão entendeu? Então a gente tem que, cara tem gente rabiscando a minha tela velho, sério mesmo ah ah, então é importantíssimo aí galera, o seguinte a gente tomar cuidado na hora de trazer temas que são complexos e de aprofundamento e tentar a gente sempre pegar em alguns temas que a gente tem um pouco mais de segurança pra responder. Obviamente, a gente vai pegar um monte de tema que nem eu, nem vocês, tem toda a segurança pra responder, exatamente pra gerar esse tipo de provocação e sentir como que a gente acaba caindo numa saia justa. Fechou? Maravilha? Então, maravilha, galera. Pessoal, lance é o seguinte. Esses requisitos, eles estão na plataforma. Espero que vocês tenham acesso porque o texto ele tá ali, tá? Então eu preciso que vocês acessem pra gente separar aí em grupos. Eu vou dar aqui exatamente a oportunidade pra três pessoas fazerem três perguntas inteligentes para vocês usarem como uma base ou como pegar alguma informação a mais que você acha que não está claro nisso que eu acabei trazendo, antes de a gente jogar vocês nos grupos, para a gente poder interagir. Fazer meio que um mensuramento do consumo de recursos computacionais dessa plataforma, desse caso de uso. Mas em nenhum momento fica claro dentro do escopo um alvo para que a gente consiga fazer essas métricas. A gente não tem uma determinada região que vai ser o alvo inicial ou uma previsão de número de usuários que a gente vai tentar atingir. Como que a gente vai poder fazer essas métricas sem uma base, sem um número base, para a gente pelo menos fazer uma estimativa, mensurar, ter uma margem de segurança sobre esses recursos computacionais sem um dado de origem. Basicamente, pelo menos para mim, não ficou claro qual seria o nosso alvo inicial e nem pelo menos um escopo inicial de atendimento, ou uma cidade para que a gente pegue o número da densidade populacional, a média de idade, qualquer coisa do tipo, para que a gente saiba qual é o nosso público-alvo. Essa é a minha dúvida. Perfeito. Eu não queria falar especificamente de plano de capacidade especificamente, mas eu vou trazer um dado claro aqui pra vocês isso já vai deixar claro que é um sistema que vai precisar de alta carga, mas independente do número que eu vou passar é importante vocês terem em mente uma coisa, tá que o sistema do tipo do Uber ele tem picos de utilização. Eu acho que tem a parte de peak users. Então o que acontece é o seguinte, nós vamos ter um milhão de corridas em um dia. Tá? E 5% dessas corridas elas vão acontecer em horários de pico. Ou seja, acabou um show, todo mundo saiu pedindo Uber, e aí vai gerar um congestionamento. Então a gente está falando de 1 milhão de corridas diárias. Tem como simular esse teste? Uma ferramenta de teste? Não vai precisar, não precisa nada disso, a gente só vai fazer o sistema design, então a gente não precisa rodar testes, nada disso, tá? E por fim, Wesley, dado esse dado que você colocou agora, esse 1 milhão de corridas, né, e o 5% do horário de pico, acredito que nesse cálculo a gente tenha que levar em consideração ações, não somente a questão dos horários de pico, né, a gente tem que levar em consideração trânsito, pra colocar a questão de taxas lá de... mais agressivas, né, vai demorar mais? Cara, tá fora de escopo taxa, cobrança de taxa. Você não vai ter que fazer algoritmo de cálculo de caixa. Isso não vai influenciar o seu System Design. Tá, perfeito. Vai influenciar na hora que eu começar a fazer umas perguntas pra vocês é como que você faria uma estimativa de cálculo de taxa baseado nesse cenário. Mas para o System Design, nesse momento, você não precisa saber disso. Perfeito. Show de bola. Perfeito? Obrigado. Show de bola. Temos agora o nosso Denogueira. Diego Nogueira. Bom, Edson, obrigado pelo espaço. Boa noite. Muito bom estar participando do evento. A minha dúvida em relação à parada é que eu não tenho contexto que é sobre geolocalização. Como trabalhar com essa geolocalização? Como que eu posso fazer uma busca de um determinado raio? E se a gente usa algum serviço? Alguma dica aí para dar para a gente? Perfeito. É mais uma pergunta importante. A gente não tem uma solução própria de utilização de mapas. Então a gente vai usar um 30-party service pra Maps. Tem diversos fornecedores. Vamos dizer que a gente vai trabalhar em parceria com a Google. Fechado? Já entrou um outro componente no sistema e um sistema externo. Aí é importante, pergunta importante. Eu trabalhei um pouquinho com o Google Maps. Show. E temos aqui o nosso amigo Júlio, vamos ver como é que vai ser a pergunta do nosso... Tá dando pra me ouvir? Perfeito. A minha dúvida, normalmente pra coisas de geolocalização como o DDOS, dá pra fazer com IP via o Nginx. A minha dúvida é, o Kong, ele conseguiria fazer esse sistema de consultar pelo IP e redirecionar pra nodes de clusters de um banco de dados específico para separar por região? Cara, eu não estou preocupado nem com a tecnologia que você está falando, se você vai usar Kong, se você vai usar qualquer outro tipo de API Gateway. O que eu estou querendo saber é como você vai estruturar o sistema. Se você quer que aquele servidor esteja mais próximo do usuário na hora que ele tiver em determinado IP, você pode colocar ali. De alguma forma. Normalmente eles trabalham isso com um hashing, né? Um consistent hashing. Normalmente quando o usuário bate, ele vai começar a bater sempre no mesmo servidor sem pensar muito por conta que fica o hash deles apontando sempre pra onde que ele vai. Mas, novamente, eu não tô preocupado com qual é o API Gateway, ou qualquer servidor web, pra mim, tanto faz. O que eu quero ver é a ideia de como que você tá estruturando a ideia. Não que não tenha sentido, não que não faça sentido. Você pode colocar ali um API Gateway que consegue, baseado em tais informações, fazer o redirecionamento pro cara de uma forma mais inteligente pra ficar mais próximo do cara. Inclusive é algo que vocês têm que pensar, tá? Porque o Uber usa uma parada um pouquinho parecida. Eu já tô dando alguns spoilers aí pra vocês. Ok, brigadão fechou? o Wesley o Alexandre fez umas perguntas aí no chat, elas também são diferentes das que foram feitas, se puder responder, se você achar pertinente também só uma pergunta, Wesley, rapidão tô ouvindo Falando só uma coisa, rapidão. Cara... Tô ouvindo. É, rapidão. Essa é a criação do diagrama visual das interações de companhias no sistema. Pra dentro, eu posso usar o modelo C4 pra modular a arquitetura? Cara, você pode fazer o que você quiser. Eu recomendo, tá? Para que um system design seja feito da forma mais fácil possível, tá? Eu recomendo que você use um Draw.io, um Scaledraw, um PowerPoint, não interessa. Eu acho que se você tiver que ficar codando e organizando, fazendo aquelas separações, eu acho que você não consegue fazer isso em 40 minutos, tá? É melhor rabisquinho. Eu tiver que ficar codando e organizando, fazendo aquelas separações eu acho que você não consegue fazer isso em 40 minutos, tá? é melhor rabisquinho, eu acho que ficaria melhor tá? mas, cara né? quem sou eu pra falar que o C4 cara, é algo que eu curto, inclusive mas dá mais trabalho, e eu não acho que pro tempo que vocês têm eu acho que é mais fácil de se expressar com os quadradinhos de uma forma mais simples na hora de desenhar, fechou? Pessoal, seguinte rolou uma hora já de nosso bate-papo então qual que é o nosso objetivo? É passar no máximo três horas aqui hoje então o que eu vou fazer? A gente vai separar vocês em salas de cinco pessoas qual é o objetivo? E eu preciso que vocês sejam bem diretos entre asas, obviamente, né? Saibam que vocês vão ter 40 minutos pra sentar, abrir o Scaledraw, vocês discutem e começam a passar por esses pontos. O que eu quero que vocês façam de cara, tá? De cara, aqui é o seguinte quais são as entidades básicas que o sistema tem ou seja, tem o motorista tem o passageiro tem isso, tem aquilo preciso que você defina as principais APIs que esse sistema vai usar e eu não preciso que você tá faça qualquer coisa complexa principais APIs que esse sistema vai usar. E eu não preciso que você, tá? Faça qualquer coisa complexa. Isso aqui, como API, já é mais do que o suficiente, tá? Ó. Post, Ride Request, Rider Location e Destination. Isso aqui já é o suficiente pra desenhar uma API de alto nível. Sacou? Nada além disso. Não precisa colocar tipagem, não precisa colocar nada. O importante é que a pessoa que olhe essa parada entenda o que está acontecendo. Eu estou olhando isso, eu estou sentindo que vai ter uma solicitação de uma request. Provavelmente já existe um token que está sendo passado para identificar quem que é o motorista e aqui eu já estou vendo que está tendo uma location e uma destination ponto, isso aqui para mim já está ótimo para eu saber que existe esse endpoint e que faz sentido ok? não precisa pirar, sei lá, colocar open API, galera, vocês tem 40 minutos, tá? O importante é, quem for olhar, consiga bater o olho e entender o que vocês estão tentando expressar. Tá longe de ser perfeito tipagem, dois pontos, location, e não sei o que, o token JWT que não sei o que. Cara, simples nessa pegada. Fechou? Maravilha? maravilha, galera, seguinte eu consegui passar em várias salas, gostei de poder passar vi que algumas pessoas seguem linhas de raciocínio diferentes e muitas dessas linhas funcionam também, então acho que isso que é a beleza da coisa. Tem algumas pessoas que adoram adicionar mais funcionalidade do que está no requisito e daí, às vezes, acaba esquecendo colocar a funcionalidade que o requisito pedia. Entendeu? Então, tem que... Cara, System Design é a maior pegadinha do mundo. Nós, desenvolvedores, a gente tem um comichão do caramba de querer colocar coisa que não está sendo pedido. Ou seja, a gente tenta implementar feature que não foi pedida para a gente implementar. E a gente gosta de fazer isso, eu não sei porquê. A gente adora complicar, fazer a mais. Então, faz parte do jogo. Agora, eu queria fazer uma pergunta aí pra vocês, que é o seguinte, quem aí tá com o System Design pronto? Não precisa ser o super pronto, o melhor System Design, mas levanta a mão aí pra mim. Gabriel Gomes, aí nós temos aqui Jair Lopes, Daniel Obara. Matheus. Pô. Aí sim, hein, galera. Show de bola. Mais 15 pessoas, mais 16. Tá bom, galera. Eu já entendi que vocês são foda. Não, show de bola. Pessoal, é o seguinte. A gente tem mais 50 minutos aqui nessa sala agora. Então, o que eu vou fazer é o seguinte, a gente tem mais 50 minutos aqui nessa sala agora. Então, o que eu vou fazer é o seguinte, eu vou pegar duas pessoas que levantaram a mão primeiro, o Jair e o Daniel. Eu vou pedir para eles compartilharem o system design deles aqui, e daí a gente vai detonar eles aqui agora, entendeu? Esses caras vão sair envergonhados da saga brincadeira, cara a gente vai trazer, a gente faz algumas considerações, mas é interessante se vocês conseguirem explicar, e já adianto tá, galera? não tem muito essa de certo e errado existe linhas de raciocínio e eu acho que o mais bacana É todo mundo poder compartilhar Entender a visão do outro Eu acho que nessas salas Eu acho que deu pra ter um contato Com outra pessoa Às vezes uma pessoa pensa um pouco diferente E é assim que acontece na vida, na empresa, em qualquer lugar A real é essa Então, nosso amigo Daniel Consegue compartilhar aí pra gente, cara? E desmuta ele, Leonel, por favor. Opa, estamos ouvindo? Opa, perfeito. Boa. Boa noite, pessoal. Caramba, fui meio que pego de surpresa aí. Levantou a mão. É que se eu falo assim, pessoal, quem quer apresentar o System Design? Quem levanta a mão, entendeu? Então, primeiro, levanta a mão. E daí... Eu vou compartilhar a tela aqui, e aí vocês me comentem se vocês estão vendo, tá? Compartilhar a tela inteira. Estão enxergando? Estão vendo aí? Estou vendo, sim. Sim? Tá. Deixa Estão enxergando? Estão vendo aí? Estou vendo, sim. Sim? Tá, deixa eu diminuir isso aqui. Bom, a ideia aqui foi tentar ser o mais prático possível, então a gente começou primeiro pelas entidades aqui, não se atentem tanto na mistura do português e inglês, a ideia foi mais separar mesmo, então a gente entendeu que ia ter motorista e passageiro, a gente até começou a trocar aqui no meio da, depois da segunda vez, enfim, motorista, passageiro e corrida são as três entidades, as maiores entidades que a gente entendeu como importantes, né, e as entidades chaves para que funcionasse esse projeto, aí depois disso a gente começou a montar que esses quadrados maiores seriam mais os microserviços, é claro que daria para entrar em mais detalhes, ter outros tipos de microserviços, mas foi o que a gente conseguiu montar ali na hora, meio que por entidade, por microserviços de entidade, só para não misturar as coisas. E aqui seria mais o fluxo das ações, desses requisitos funcionais que a gente foi criando. Então, aqui o nosso passageiro, ele faz a solicitação, que é a tal solicitação do orçamento, para não ter um problema ali de muita requisição de orçamento, a gente joga isso para uma fila, cria o orçamento em si, que é a corrida, né? Essa corrida vai pra uma outra fila, que vai ser a fila que vai ser consumida pelo pelo driver, né? Inclusive, essa fila aqui, depois de ser inserida esses dados aqui, vai ter o push notification, vai enviar as informações que a gente colocou aqui, de uma forma bem crua, o valor, o destino e as informações básicas do passageiro. Espera um pouquinho, desculpa te cortar, meu amigo. Vamos lá, vou ler primeiro o pré-requisito. O passageiro deve solicitar uma nova corrida, informando a localização e obtendo o valor. Onde que ele está obtendo o valor de volta aí? Aqui, na verdade, não exatamente nessa linha, né? Mas a ideia é que ele vai ter o retorno aqui, ó, da solicitação de orçamento aqui embaixo. Logo depois que inserem nessa fila, né? Isso aqui, ela já volta pra ele o... a response, né? Dessa request que ele fez. Ah, mas daí você manda a push notification mesmo se o cara não aceitar o orçamento? Não. Essa push, na verdade, fica aqui embaixo, né? Ficaria mais pra baixo. O que tem aqui embaixo, ó. O aceitou, se ele inseriu na fila, ele inseriu na fila, se o motorista ele aceitou, insere na fila de novo. Não ficaria aqui em cima, ficaria mais pra baixo. Tá. não ficaria aqui em cima, ficaria mais para baixo. Beleza, e aí depois disso vai ter a parte que ele vai ter aqui de confirmar o início da corrida com base na solicitação anterior, então como ele tem o retorno dos dados aqui da solicitação dele, ele vai ter um update ali na solicitação, e aí vai atualizar, aí essa fila que é consumida, que na verdade entra essa parte aqui do nosso driver, vai ter a notificação para ele, se ele aceitou, beleza, ele aceitou, volta a informação para o nosso passageiro, se ele não aceitou, vai inserir na fila de novo. Isso foi o que a gente conseguiu fazer o macro. Aí entrando um pouquinho mais de detalhes de endpoint, a gente também foi bem genérico aqui, não entrou tanto em detalhes do que exatamente a gente está enviando, mas vai ter os crudes de usuário, e usuário a gente já entende tanto sendo motorista quanto passageiro. A parte de localização também, então, como a gente entrou num detalhe que era o rastreio ali, meio que, entre aspas, tempo real, o que a gente surgiu de imediato foi o WebSocket para utilizar nessa questão de acompanhar pelo mapa. Post é para criar mesmo, seja ele motorista ou passageiro. O CRUD da corrida vai ter os dados da corrida em si. O update vai ser bom para atualizar status e claro que vai ter alguns outros endpoints, mas isso foi que a gente fez de uma forma genérica, que a gente sabe que vai ter o update dos dados da corrida, que tem muita interação, né? Que essa daqui que é a chave, uma entidade chave, então vai ter muita interação, muitos updates por aqui, e a criação dela em si. Então, o crudizão básico ali que a gente já sabe dos dados que a gente vai ter que enviar, né, sabe, entre aspas. E tem aqui um pouco do diagrama da entidade de relacionamento, do como que funcionaria, e aí entra um pouco mais em detalhes do que que tem uma ideia, do que que a gente enviaria, ou até pegaria nos dados. E aí, isso foi isso. Show. Cara, eu vou dar alguns dois centavos, tem algumas coisas que eu vou falar na hora que eu for mostrar o meu, tá? Mas, cara, achei legal a ideia de como que você separou, tentando fazer como se fosse uma sequência. A dica que eu daria, tá? E, novamente, falo de novo pra todo mundo, galera. Tomem muito cuidado com o System Design, porque vocês acabam colocando requisitos que não tem. Por exemplo, o design de API que você colocou ali, você não fez o design de API que você colocou ali, você não fez o design de API. Sobe ali. Sobe. Aqui. Você colocou CRUD corrida, GET corrida. Cara, esse design de API, ele tem que representar os requisitos. Entendeu? Então, por exemplo, CRUD de user. Eu pedi em algum momento para criar usuário? Não, não. Não deveria ter, sacou? Aham. Update corrida eu vou update do que da corrida sacou? todos os seus endpoints eles sempre tem que corresponder com os requisitos exatamente o que a gente está implementando exatamente isso porque a sacada é o seguinte se você sabe os endpoints Que você tem, na hora de você Fazer esse desenho seu do System Design O que você vai fazer com o desenho? Você vai implementar cada uma Dessas APIs em formato De diagrama Não sei se fez sentido O que eu tô querendo dizer Sim, sim Então, por exemplo, se o passageiro deve solicitar uma nova corrida, então eu tenho o passageiro, né, batendo num serviço de corrida, né, para pegar um orçamento. Opa, para pegar um orçamento, o que eu preciso saber? Bom, eu vou solicitar um orçamento. Então, como que eu solicito um orçamento? Ele vai bater. Para eu ter o orçamento, eu tenho que saber os motoristas para eu concluir o preço. Então, eu vou ter que ter, provavelmente, a localização de onde o cara está, onde ele quer ir. Aí, provavelmente, eu vou ter que ter um match para ver os motoristas que eu tenho disponível naquela área. Baseado nisso, eu vou ter. Com isso, eu consigo fazer o quê? Eu consigo cair num sistema de serviço que calcula para mim o orçamento. Ok? Aí devolvo para o usuário final o orçamento. Aí, o cara aceitou. O cliente falou, vamos começar a corrida. Beleza, então, aceitei, criei uma nova corrida baseado naquele orçamento. Então, agora, eu vou cair ali e eu vou ter que fazer o match dos motoristas pra ver qual é o motorista que vai aceitar. Aquele motorista que eu fiz o match vou mandar a notificação. Ele aceitou? Iniciou a corrida ali pra mim. Basicamente são esses três requisitos. Mas a gente tem alguns outros pontos. Mas vamos seguir cara, mas eu gostei de forma geral que você teve o trabalho aí de separar, dizer o que cada um tinha e etc eu acho bacana isso normalmente essa representação que você está fazendo dessas entidades com as propriedades, cara, normalmente isso é muito feito na parte de system design na hora de fazer a modelagem do banco de dados em alto nível. Mas, normalmente, não é muito feito para você modelar API ou algo desse tipo. Então, isso é bem interessante para quando você for pensar em banco de dados. A gente vai acabar falando sobre isso amanhã. Mas, é interessante saber porque você consegue ter uma ideia de como que as informações são estruturadas e provavelmente independente do tipo de banco de dados se é relacional, se é no ciclo etc, de uma forma ou de outra relacionamento sempre vai ter tá? Então é interessante que você tenha esses dados mesmo e tudo mais tá, mas novamente, você não pode você não precisa ficar tão preso a detalhes que não estão no requisito por exemplo, driver's license cara, eu não tô preocupado não tem um requisito, apesar de ser óbvio, que o motorista ele tem que ter habilitação então tipo assim, se é uma pessoa que tá te entrevistando numa big tech e eu falo de motorista, ele tem que ter habilitação. Então, tipo assim, se é uma pessoa que tá te entrevistando numa Big Tech e eu falo de motorista, cara, já é inferido que o cara tem habilitação. A não ser que ele fale e fale assim, cara, quais são as propriedades que você acha que um motorista tem que ter? Aí é um outro nível de pergunta. Mas quando você tá pensando em high level, evita esses tipos de detalhe. Ah, o e-mail, o telefone, a não ser que o telefone represente algo tão importante no sistema naquele momento, entendeu? Baseado nos requisitos que a gente tem aqui, eu saber se o cara tá ativo no sistema ou não tá, não tá no requisito, tá? O driver, se ele tá ativo pra mim ou não, nem existe esse status no sistema, sacou? Então, galera, a dica que eu tento sempre dar pra todo mundo siga a cartilha exatamente como tá, porque se você cai numa entrevista de system design, você vai ter literalmente 50 minutos pra fazer tudo isso e mais o plano de capacidade com um monte de conta se você gastar um tempo pra mostrar uma API de crude que que não faz parte, você gastou cinco minutos do seu tempo precioso e ainda o entrevistador ainda pode pensar, esse cara tá de sacanagem comigo, que ele tá querendo fazer a definição de, se o cara tem licença de motorista, pô, entendeu? Mais ou menos isso. Então, tenta sempre, cara, assim, tem que ser um sniper mirando... Pragmático, né? Ser mais... Muito, muito. É, porque aqui foi mais uma junção, né? A galera se separou ali... Deu pra perceber completamente o seu raciocínio, entendeu? E tá legal. Eu acho que o que falta mesmo é esse alinhamento de, um, identifique a entidade, dois, fiz o design da API, três, fiz o desenho. Entendeu? Fechou? Vamos pra... Aí show de bola, cara, velho. Saiu. O ponto é esse. O ponto importante é saiu o system design de uma forma ou de outra, saiu. Dá pra melhorar? Dá. Dá pra fazer pior? Dá pra fazer melhor? Dá pra fazer de milhares de formas? Dá. Entendeu? Mas saiu. Eu acho que esse é o ponto importante aqui beleza? a outra pessoa que ia fazer que tinha levantado a mão em seguida quem que era? eu vou pela ordem aqui que eram duas pessoas, acho que era o Patrick era isso Patrick que você tinha levantado, né? é você, você que tinha feito, né? levantou a mão, levantou a mão vai ter que mostrar ou é o Jair? eu sei que tinha feito, levantou a mão levantou a mão, vai ter que mostrar ou é o Jair tinha outra pessoa, mas eu acho que eu subi em seguida não sei foi eu e o Daniel que tinha levantado primeiro, Jair aqui bota aí Jair, manda ver beleza posso abaixar a mão? pode deixa eu pegar a tela aqui. Se estiver vendo, me fala, tá? Tá compartilhando aqui já. Show de bola. Beleza, então deixa eu já começar pedindo desculpa. Não, brincadeira. Pelo amor de Deus. Aqui, mas aqui a gente começou então pelo primeiro requisito, néito de chamar a pay de orçamento. A ideia é que o cliente do passageiro vai fazer uma requisição para um serviço que vai fazer o orçamento. Então a gente vai usar um serviço Google para calcular a trajetória e quantidade de tempo que ele vai levar e em cima disso botar ali o orçamento né e devolver aqui para o cliente então nessa requisição ele vai mandar ali o ID do usuário início e fim da corrida e a gente vai usar esse serviço e vai armazenar a corrida aqui numa base né de simulações aqui e vai voltar para ele o ID da corrida aqui numa base, né, de simulações aqui. E vai voltar pra ele o ID da corrida, que aí ele vai poder confirmar ou não a corrida. No momento em que ele confirmar, aqui ele vai mandar uma requisição pra nossa, pro nosso matcher, né, pra API que manda as notificações. Então, esse matcher, ele vai mandar uma notificação aqui no serviço de mensageria, depois vai pedir um endereço aqui de WebSocket e vai devolver esse endereço de WebSocket para o cliente do passageiro, porque esse cliente do passageiro vai ficar plugado no WebSocket temporário dele aqui, até receber uma notificação de algum motorista que tenha aceitado ou não a corrida dele, ou que seja cancelada. Então, vamos para o cenário onde ele vai procurar aqui um motorista. Então, aqui, no cenário onde ele vai procurar aqui uma corrida, no cenário onde ele vai procurar aqui uma corrida, o serviço de notificação aqui, a mensageria, vai notificar um match rider service aqui para procurar um motorista, e esse match rider vai calcular ali quais motoristas são mais próximos ali, vai listar os motoristas mais próximos, e vai oferecer a notificação, dependendo dos critérios que a gente definir, vai oferecer a corrida para o primeiro motorista. E vai ficar ligado também aqui, ele vai estar conectado num WebSocket específico onde os clientes dos motoristas vão estar conectados. Quando o motorista estiver ali esperando o corrida, ele vai estar conectado no WebSocket. E aí esse match rider vai ficar conectado nesse WebSocket também. Então no momento em que ele notificou o primeiro motorista e o motorista aceitar, ele vai mandar uma mensagem ali para o WebSocket do cliente. Por isso que nessa etapa anterior, até desculpa voltar aqui o raciocínio, mas na etapa anterior, ele vai primeiro gerar esse endereço para depois enviar, é que a gente colocou aqui antes, mas ele vai primeiro gerar esse endereço para depois enviar a notificação, porque ele já vai ter o endereço desse WebSocket aqui na notificação. Então, no momento em que esse Match Rider Service está conectado aqui no WebSocket dos motoristas e viu que tem uma uma aceita de corrida, ele vai conectar nesse WebSocket do passageiro e vai avisar o passageiro. E aí o passageiro vai ser avisado. Se o motorista negar a corrida, ele vai procurar o próximo da lista, vai notificar, e esse próximo também vai estar conectado ali no mesmo WebSocket. Então no momento que esse próximo aceitar, ele vai devolver aqui para o MatchRider e vai voltar aqui para aquele fluxo de avisar o passageiro e o passageiro aceitar. Então, passados dois minutos, ele vai mandar uma mensagem aqui para aquele fluxo, né, de avisar o passageiro e o passageiro aceitar. Então, passados os dois minutos, ele vai mandar uma mensagem aqui para o passageiro de que a corrida foi cancelada, de que nenhum motorista aceitou, e aí a corrida vai ser cancelada. Aí aqui as entidades a gente colocou numa aba paralela, tá? Então aqui é como entidade de negócio A gente identificou que tem os passageiros Motoristas, corridas E uma tabela auxiliar aqui para status de corrida Por exemplo, a gente pode fazer uma corrida E ela não ter sido aceita nunca Então ela fica em status de pending ali Ou então essa corrida foi aceita pelo passageiro Mas não por um motorista Então ela fica lá, recusada por motorista E por aí vai Aqui está meio que copy paste Porque a gente estava desenvolv mas não por um motorista. Então ela fica lá, recusada por motorista. Então aqui tá meio que copy-paste, porque a gente tava desenvolvendo aqui as tabelas na hora que acabou o tempo, mas seria isso. Show. O que é essa pontuação aí do motorista, velho? Ah, isso foi uma firula aqui. A firula, né? Eu tava aguardando a firula, não é que eu vi pompação É firula Os caras não se aguentam Não aguenta, né? Tem que pôr uma pena no palão Não será abordado Sistema de avaliação De motoritas e passageiros Notas de 5 estrelas Não, mas de boa Cara Eu gostei de algumas coisas que vocês fizeram. Gostei de bastante coisas que vocês fizeram. O que eu gostei é que vocês definiram as entidades e para cada endpoint você criou um system design. Então, ficou bem claro o que cada um desses gráficos, desses desenhos acabaram ficando. Então, você realmente criou o design das APIs e implementou o system design baseado naquele processo. Então, eu acho que isso é bacana. Agora, o que normalmente acontece, sabe o que é? É que quando você começa a separar, e não que isso não seja útil, isso que você fez é muito útil, inclusive, para quando você quer definir e focar somente naquele tipo de processo. Mas quando a gente está pensando em System Design, às vezes a gente quer ter a visão um pouco mais ampla de tudo o que está acontecendo no sistema. Então, eventualmente, vale a pena você ter a visão um pouco mais ampla de tudo que está acontecendo no sistema. Então, eventualmente, vale a pena você ter uma visão consolidada de tudo o que está acontecendo aí nesses pontos, ou seja, para cada tipo de serviço, micro serviço. E é interessante também, galera, de forma geral, você sempre, por exemplo, ali, de forma geral, tá? Você sempre, por exemplo, ali, pode parecer besteira, tá? Mas pode ser, às vezes, até uma pegadinha que vocês podem cair numa entrevista. Por exemplo, o passageiro mandou um post pra uma API pra notificação. Daí eu falo, poxa, o rei esquisito não funcional fala que vai ter um milhão de visitas. Será que um cliente mandando um post para uma API aguenta isso? Será que não tinha que ter, sei lá, um WebFile na frente, depois um API Gateway, um Load Balancer para conseguir escalar essa API? Então, às vezes, parece óbvio que isso vai ter, se você está falando uma aplicação de milhões, mas vale a pena no System Design você sempre colocar isso, tá? Bota sempre um Load Balancer na frente porque você já indica nesse momento que você já tá pensando em escala, entendeu? Em diversos aspectos. E normalmente quando você consegue e começa a colocar esses tipos de componente, você também já dá a entender para a pessoa que, ah, eu sei como é que funciona um load balancer, eu sei como é que funciona um API gateway, eu sei que aqui vai bater num banco de dados, eu sei que esses bancos de dados podem ser bancos de dados diferentes, porque são serviços diferentes, tá? É legal que você trabalhou com, já começou a colocar a comunicação assíncrona e coisas desse tipo. Sempre quando vocês fizerem um System Design, tente ver a big picture. A pessoa olhou aquela parada, a ideia é ela conseguir ver o sistema inteiro, com todos os processos. É confuso, inclusive, você conseguir entender todos os processos no sistema inteiro no único System Design. Mas normalmente esse exercício é exatamente isso, para você ver a big picture. O que eu daria como sugestão pra você fazer depois e depois se você quiser você manda pra mim amanhã, a gente pode olhar isso, tenta consolidar tudo isso num só tá, e separa o design da API dos desenhos fez sentido o que eu tô querendo dizer? não, total. Fez sim. Fechou? Mas eu gostei que você foi criando o System Design para cada parte do processo, de cada requisito. E isso aí para a gente é importante, porque faz parte do sistema de forma geral. Pessoal, seguinte, o que eu vou fazer aqui? Você pode compartilhar? Só pra... Aí. Galera, o que eu vou fazer agora aqui vai ser o seguinte, tá? Tem alguns pontos importantes. Um ponto é que vocês precisam ficar até o final, porque eu tenho que dar algumas... Eu preciso que você preencha uma paradinha, e eu vou mostrar como que eu fiz a primeira parte desse System Design. E, novamente, eu não estou falando que o meu está longe de ser o melhor do mundo ou qualquer coisa desse tipo, tá? Mas eu quero contextualizar o porquê que eu criei ele desse jeito e o porquê que amanhã ele vai ser mudado, tá? Beleza? Então é só para tentar deixar isso bem claro, porque se vocês pegarem o System Design que eu vou mostrar hoje para vocês postarem o System Design que eu vou mostrar hoje pra vocês postarem no LinkedIn, vão falar que eu não sei nada de System Design, tá? Não que eu seja um gênio do System Design, tá? Mas vocês vão entender do que eu tô falando na hora que eu mostrar isso aqui pra vocês. Mas ele tem uma lógica aí importante pra cadência do evento. Eu vou mostrar ele de um jeito e amanhã a gente vai mudar ele baseado no que a gente aprender amanhã em relação à parte de comunicação entre microserviços, sistemas, formas e tudo mais. Então esse é um ponto importante. Galera, uma outra coisa que eu não posso deixar de falar, tá? E eu vou falar isso já agora e também vou falar isso depois, tá? Mas eu não posso deixar de falar, obviamente, né? Todo mundo tem que ter o seu momento jabá, tá? Eu não sei se vocês sabem, mas aqui na Full Cycle nós também, tá? Não temos só curso Full Cycle oucle, nós também, tá? Não temos só curso Full Cycle ou qualquer coisa desse tipo, tá? A gente, inclusive, deixa eu compartilhar a tela, deixa eu compartilhar o System Design e o que eu queria trazer aqui pra vocês. Pera aí. Como que eu compartilho a minha tela inteira? Bom, vou compartilhar a tela inteira, né? Que eu não sei compartilhar do outro jeito. Show. Seguinte, galera. Antes de eu ir para o meu System Design, eu queria trazer uma coisa importante aqui para vocês. Para a gente é importante, para vocês talvez seja importante também. Aqui na Full Cycle, a gente tem o nosso programa de MBA. E por que eu estou falando isso agora? Porque ainda nessa semana, a gente está numa fase de pré-matrícula. E na fase de pré-matrícula o valor do MBA é reduzido. Porque a partir da semana que vem o valor dele não vai ter um valor especial de pré-matrícula. Então se você estiver interessado em entender como é que funciona o nosso programa, todos os detalhes, etc, etc eu vou te passar um link aqui no chat tá, cadê o chat de todo mundo não sei olhar o chat cadê meu chat aqui está o chat eu vou passar aqui no chat, tá a um link pra todo mundo, everyone. Como é que eu mando pra everyone? Porque senão eu vou mandar pra um tal de Gabriel. Espera um pouquinho. Ô, Leonan, cola pra mim o link, cara, por favor. Agora. Tá? Tá? Tá? São dois links. Um link a gente vai pedir também para vocês só fazerem uma pesquisa do que vocês acharam de hoje. Mas, caras, o lance é o seguinte, tá? Esse nosso programa de MBA, obviamente, ele tem área também de System Design, mas ele, cara, são basicamente 18 meses de curso onde a gente foca muito em arquitetura de solução arquitetura de software DevOps, SRE e uma área só de soft skills e a grande sacada é que a gente trouxe e a gente tá trazendo sempre gente animal pra conseguir dar aula, então a gente contratou o Uncle Bob onde ele gravou toda a parte de Solid a gente contratou o L., onde ele gravou toda a parte de Solid. A gente contratou o Alistair Coburn só pra parte de... Nesse caso, na parte de arquitetura hexagonal, que ele que fez a parada da criação da arquitetura hexagonal. Mas a gente tem um monte de gente, assim, fantástico que participa. O Warren Haney, ele é o criador do RavenDB. O criador do RavenDB, o cara cria banco de dados, velho. É um dos caras mais famosos aí também na comunidade Microsoft. O Fabian Riesenkamp, ele é um especialista em System Design da Microsoft, que também tá ali com a gente. Tem o Elemar, que ele vai fazer uma talk com a gente, o Rodrigo Branas, o Fernando Costa da Google, a Roberta, a gente só tá esperando. A Roberta foi pra Google agora, né a Roberta foi pra Google agora e aí a gente precisa esperar a Google liberar ela e voltar a palestrar tem a Thaisa, a Loiane, o Juliano o Martins, o Ricardo que está na Redis agora, o Swack do Mercado Livre o Albert Tanuri, o Eduardo Dias o Cássio cara, tem muita gente top que participa e faz participações com a gente, então depois eu super recomendo que vocês deem uma olhada na página do nosso MBA, porque a gente está com um valor de pré-matrícula que vale a pena e vocês já começam a estudar agora em fevereiro para um valor mais baixo. Então, cliquem ali no link do chat que o Leonan passou aí para você. Você passou, Leonan? Já passei, estou colando de novo. Tá, ele tá colando, esse link ele dá direto conforme você preenche, a gente entra em contato e tem um ponto importante, tá? O MBA não necessariamente é pra todo mundo em todo momento da carreira. Por isso que a gente prefere muito mais senta, apresenta, mostra o que é, entende o seu momento, pra ver se ele faz sentido naquele momento. A última coisa que a gente quer é você se inscrever numa parada e não vai fazer sentido no seu momento profissional agora, tá? Então, clica aí nesse link, depois eu passo um QR Code também aí para vocês que fica mais fácil de colocar. Mas, cliquem, entrem em contato aí com a nossa galera. Durante essa semana, a gente consegue entrar com o valor de pré-matrícula. Depois disso, o valor sobe. Ok, está tudo bem se vocês quiserem poder participar, mas daí já é um com valor maior. Então, eu recomendo aí que vocês, pelo menos, preenchem o form, a gente baixa um papo, totalmente sem compromisso, Preencha um form, a gente baixa um papo, totalmente sem compromisso, e eventualmente faz sentido você participar. Porque a gente vai falar desde arquitetura de solução, arquitetura de software, system design, design docs, Kafka, banco de dados, cloud computing, edge computing, arquitetura de software, domain driven design, solid, arquitetura hexagonal, microserviços, arquitetura baseada em eventos, containers, kubernetes devops, sre, infra, zcode cara, tem coisa pra caramba, tá? é coisa pra caramba e a gente trouxe os melhores pra conseguir dar aulas aí pra vocês, cara então a gente tá mega feliz com o que a gente fez nesses últimos tempos então, tá mais do que todo mundo convidado, cliquem no link que o Leonan tá colocando aí no chat para vocês. E aí eu quero ver vocês baterem um papo. Muitas vezes eu também bato papo com os alunos para explicar como é que funciona. Aí se fizer sentido, vocês estão mais do que convidados aí poder participar. Fechou? Agora, acabando o momento jabá, vamos falar sobre o lance do System Design. Isso aqui foi o desenho inicial que eu trouxe e que eu deixei disponível na aula. Mas, obviamente... Opa, espera um pouquinho. Como que eu escondo esse meu cara? Mas, obviamente, que isso aqui era um exemplo que eu estava querendo dar de como que você podia fazer um design de uma API, como que você poderia ter uma ideia de fazer uma relação aqui de um system design ou qualquer coisa desse tipo, tá? Eu tenho uma colinha aqui pra não ter que ficar desenhando tudo do zero aqui com vocês, tá galera? Inclusive hoje no YouTube teve um cara que falou que eu tava colando pra gravar o vídeo num outro monitor e isso mostrava a minha incapacidade técnica daí eu falei assim, poxa cara, me desculpa cara, desculpa de eu ser tão incapaz porque eu uso dois monitores pra fazer as minhas aulas mas tudo bem galera, o lance é o seguinte pra gente tá claro e como eu falei pra vocês as entidades ou relacionamentos de entidades, mesmo que sejam mais fortes ou entidades que sejam mais fracas, ou entidades core. E quando eu falo entidade, normalmente a gente divide isso em duas coisas. Entidade mais forte mesmo, são caras que têm um ID. Tudo que tem um ID, que é único dentro do sistema, é considerado uma entidade. Existem outros caras que representam algo importante no sistema, não necessariamente é único, mas ele tem uma relevância muito grande e que às vezes ele é utilizado e muita gente acaba dependendo dele. Normalmente a gente chama isso de objeto de valor, value objects, porque eles são imutáveis, mas eles não são únicos. Essa que é a grande ponta. Então aqui foi da forma como eu mapeei. E não estou dizendo que a minha forma é a correta. Provavelmente se eu fosse fazer isso do lado de uma pessoa que trabalha na Uber, o cara ia falar fala inocente, você está muito inocente porque você está mostrando aqui pra mim, entendeu? Mas a alto nível pela proposta que a gente tem aqui e baseado naqueles três pontos dos requisitos que eu coloquei, eu encontrei esses três caras, tá? Esses caras aqui na realidade. Tá? Um cara aqui é o passageiro. Eu tô chamando ele de rider, tá? Tem a corrida, que é a ride, não é rider. É ride, né? Ou a trip, do jeito que você quiser chamar. Localização que normalmente ela pode ser dividida entre pickup location ou destination, onde que o cara vai ser peida entre pickup location ou destination, onde o cara vai ser pego, onde vai ser largado. A localização, de forma em geral, se você olhar, ela não é algo único, se você perceber, né? Se eu pegar várias vezes no mesmo ponto, não necessariamente é algo... Dependendo da situação, você não pode considerar isso como uma entidade. Mas ela tem uma força tão grande no que a gente faz, principalmente para o tipo de negócio que o Uber é, que ele é baseado em geolocalização para o tempo todo. Na minha opinião, esse cara é um cara muito relevante aqui, por isso que eu estou colocando ele aqui. Aí a gente tem o valor da corrida, que faz parte do requisito inicial. O valor da corrida, a FAIR, o orçamento prévio, que é a FAIR Estimate. E a gente tem a parte onde a gente precisa notificar, a gente precisa tanto notificar o motorista quanto o driver, porque tem as localizações e tudo mais. Agora, o grande ponto daí é design da API. O design da API, galera, ele deve sempre tentar ser feito baseado nos requisitos, tá? Então, vamos... Deixa eu olhar aqui que eu tenho uma cópia dos requisitos no meu outro monitor, porque eu sou incapaz de fazer as coisas. Cadê aqui, meu cara? Aqui. O passageiro deve poder solicitar uma nova corrida, informando uma localização de origem, um destino, obtendo o valor estimado da corrida. Então, basicamente, o que o cara quer aqui é um orçamento, certo? Basicamente, o que ele quer aqui é um orçamento. Então, deixa eu colocar isso aqui, e daí a gente discute em cima disso, tá, galera? Não estou dizendo que é verdade absoluta, mas é um ponto de partida aqui, tá? Então, o que eu tenho aqui no design.ti? Eu estou dizendo que é um post, porque eu estou criando algo novo, simples por conta disso. Então, eu tenho o FERS, que são as taxas que a gente vai trabalhar, e Estimate, que é o orçamento, e aqui eu posso até colocar um comentário que pode ter um token que vai identificar o rider, ou eu poderia colocar aqui o rider ID, que é o cara de quem está pedindo, mas novamente, eu acho que o ponto principal aqui não é você querer ficar dando muito detalhe. Por quê? Ah, created at, updated at, se o token é isso, se isso é aquilo. Cara, nesse momento, eu quero entender a ideia de alto nível do sistema. Então, eu sei que eu estou pedindo um orçamento, que esse usuário está pedindo um orçamento baseado na localização que o cara vai ter um pickup e na destination e eu vou ter um resultado, uma response do fair ID e o preço que eu vou que eu tive que retornar, por exemplo, aqui pra mim ou só o fair ID, eu estou colocando o preço pra quê? pra deixar mais expressivo pra não dizer que eu vou ter que ficar consultando o ID com o preço. É pra deixar expressivo. Eu acredito que todo mundo que tá olhando isso entendeu o que esse negócio faz. Concorda comigo? Espero que sim, né? Tá bem transparente o que esse cara faz. Certo? A gente tem um outro cara, né? Que é o seguinte. Qual que é o seguinte qual que é o outro requisito? alguém consegue ler pra mim? é, o passageiro pode confirmar o início da corrida com base na solicitação anterior, onde ele já tem o orçamento, ok? então, cara, aqui no final das contas, como que esse cara confirma? né, eu vou fazer um post solicitando uma nova ride baseado naquele fair ID que foi o orçamento que eu fiz antes acabou não tem muito segredo em relação a isso estou criando uma nova corrida agora baseada num estimate poderia e aí tem duas interpretações que eu acho que as duas são bem plausíveis eu poderia aqui ter uma ride onde o cara recebe faz o request da ride, recebendo a estimate, e depois ele tem um ride confirmation passando o id da ride, falando que ela pode começar também funciona também, né, se você pensar bem eu tô partindo do princípio que eu tô lidando com o orçamento primeiro, para depois lidar com a ride. Para não precisar iniciar uma nova corrida, criar uma corrida no sistema antes do cara saber o preço. Só estou partindo desse princípio. Mas eu acho que é super aceitável o cara colocar um ride request, receber no orçamento, daí um ride confirmation, por exemplo passando o ID da ride que ele tá confirmando acho que não tem problema nenhum tá? Aí o que que acontece? Eu preciso o que nesse momento? Que o motorista, de uma forma geral né? Ah... né? Ele aceite a ride também, né? Porque ele faz a requisição da ride e vai aparecer a confirmação ali também se ele precisa aceitar ou não então, o que que acontece tanto o meu querido motorista, né ele pode falar que nessa ride ele aceitou, nessa ride, tá ele fez a requisição. Tem o orçamento. Quer confirmar? Quero. Aceitei o rider aqui. Então eu mantenho um patch aqui para ele. Só para dizer que eu estou atualizando o registro. Falando que o rider, né? O viajante, o passageiro, ele aceitou. Por outro lado, eu preciso também de um outro cara. Que Eu preciso também de um outro cara que pode ser o mesmo endpoint, mas que esse cara aqui seja o status do driver, para dizer se o motorista aceitou ou não. Perceba que nesse momento, galera, eu não estou pensando no fluxo. Eu estou pensando nos requisitos do que pode acontecer naquilo que a gente acabou colocando. Tá? Tá fazendo sentido pra todo mundo o que eu tô colocando, galera? Beleza. E aqui, a gente precisa de uma outra coisa. Que a gente vai precisar traquear, né? E saber a localização desses caras. Então, pra cada ride em alguma forma eu preciso saber a localização atual de como que tá aquela corrida certo? então toda vez que eu mudar uma localização dependendo da situação eu posso atualizar a localização onde eu falo que eu tenho o driver ou o rider atualizando a latitude a longitude e o timestamp dele então nesse momento essa ride eu sei onde que o cara tá é um snapshot daquele momento como é que essa ride ela vai tá por outro lado aqui eu estou atualizando o dado da ride ou seja, da minha corrida, aonde está o motorista e aonde está o meu passageiro. Fora isso, eu tenho que poder consultar esses dados, porque eu preciso pegar o tempo todo a localização desses caras. Então, provavelmente, eu vou precisar daqui de um get para eu conseguir trabalhar e conseguir escolher se eu quero pegar a localização. Pode ser de todo mundo, ou só do driver, ou só do rider aqui para mim, onde eu vou pegar a latitude, a longitude e o timestamp aqui também. Se vocês perceberem, galera, esses tipos de desenho de API aqui de forma geral, é algo extremamente simplificado. Vocês conseguem se ligar? O que eu estou querendo dizer? Você não precisa ter muita firula, porque os dados óbvios, você não precisa colocar. Você coloca só os dados que realmente valem a pena ser mais relevante. Eu não vou colocar drivers license do motorista aqui, entendeu? Porque é óbvio que o motorista já tem carteira de motorista aqui. Entendeu? Porque é óbvio que o motorista já tem carteira de motorista. A não ser que tivesse um requisito que é verificar se o motorista tem carteira de motorista. Aí mudou a história. Aí a coisa mudou, entrou um novo endpoint, entrou um novo processo. Enquanto não tem isso nos requisitos, a gente ignora. Beleza? E aqui que vem agora a parte que é mais polêmica, tá? E eu estou dizendo polêmica da forma como eu estou colocando isso hoje. E novamente, tá? Eu vou falar isso dez vezes só para não gerar nenhum ruído de comunicação e colocando que eu estou explicando errado ou que eu estou fazendo um system design da forma como eu vou apresentar agora só para deixar claro porque isso vai ter que mudar completamente para amanhã legal? a lógica que eu quero trazer aqui para vocês é que se eu conseguir o meu system design incluir todas essas APIs porque cada API dela resolve um requisito funcional de forma geral em tese eu tenho meu System Design, faz sentido isso que eu estou dizendo? eu tenho os requisitos se eu tenho os meus requisitos e tenho as ações que esses meus requisitos fazem se eu conseguir representar essas ações através de um System Design, em tese o meu System Design tem tudo que eu preciso. Tá? Em tese, porque tem 10 formas, 10 milhões de formas de fazer um System Design. Mas, novamente, é um ponto de partida de algo básico. Isso eu sei que é um mínimo, porque não faz sentido eu ter esse endpoint como um desenho de API, e isso não estar no meu System Design. Vocês concordam comigo? Tudo isso que eu estou colocando aqui tem que estar no meu desenho do System Design de alguma forma. Se isso aqui não estiver no meu System Design, quer dizer que o desenho que eu estou fazendo, ele está incompleto. Então, essa aí é o nosso grande ponto. Então, esse design de API aqui, ele é muito mais para a gente saber as funções que o sistema está fazendo, do que necessariamente a gente falar em API, galera. Porque a maioria dessas caras aqui nem vão utilizar API REST na maioria das vezes. A maioria desses sistemas vão trabalhar com GRPC, com milhões de microserviços atrás se comunicando, tá? Aqui ele muito mais mostra o que funcionalmente o sistema vai conseguir fazer. Então, baseado nisso, tem aqui primeira versão do System Design que eu vou trazer hoje aqui para vocês. Essa primeira versão vai partir do princípio que eu apenas quero garantir que todos os requisitos que eu estou colocando aqui estejam cumpridos. Mas eu não estou levando em conta aqui uma coisa por hora. Que é o quê? Grande parte dos requisitos não funcionais. Como que você vai fazer um system design que não leve em conta os requisitos não funcionais? Na realidade, você não faz um system design desse tipo que eu vou fazer agora. Por que eu vou fazê-lo agora desse jeito? Porque amanhã a gente vai falar muito sobre comunicação entre sistemas. E essas formas de comunicação são formas que vão nos ajudar a identificar os requisitos funcionais e saber como que a gente vai alterar esse system design para ele ficar de uma forma mais adequada, mantendo resiliência, mantendo disponibilidade, mantendo disponibilidade, mantendo a parte de consistência de dados e coisas desse tipo. Mas o objetivo agora é garantir que tudo que a gente colocou até aqui em cima seja implementado de forma visual com grafo. Então é o seguinte, eu vou tentar fazer isso aqui o mais passo a passo possível, porque acaba virando um monte de rabisco, principalmente da forma como eu fiz agora aqui pra gente trabalhar. Então, primeira coisa que eu tenho aqui é o rider, né? O passageiro, né? Esse é um cara que eu tenho aqui. Uma coisa que eu vou fazer, tá, pessoal? E isso eu recomendo pra qualquer tipo de sistema de design. Como, de cara, a gente sabe que esse tipo de sistema, ele vai ter que ser um sistema que vai escalar, e principalmente pelo fato de que a gente nem falou sobre autenticação, autorização, a gente não falou de segurança, a gente não falou um monte de coisa, como que é uma forma que você pode amenizar essa sua sensação daquele comichão que a gente tem. Poxa, não falei de sistema de login, não falei disso, não falei do cadastro do usuário, não falei da segurança, não falei de um monte de coisa. Você fala o seguinte, cara, eu tenho motorista e aqui eu tenho um API Gateway. Esse API Gateway aqui, ele vai cuidar de um monte de coisa para mim, tá? E aí você pode até falar lá pro seu entrevistador, pro pessoal da sua empresa. Esse cara vai verificar a autenticação, ele vai fazer tratamentos, logs, ele vai colocar filtros, esse cara vai conseguir fazer um um monte de coisa aqui. Então, o que você pode fazer aqui no API Gateway, no final das contas, é falar, tudo que vai acontecer de comunicação no meu sistema com o usuário final, vai passar por aqui e acabou. Esse cara vai saber pra onde rotear, pra qual serviço vai sair e o meu cliente final não vai saber o que acontece por dentro do meu sistema. Então, começa por aí. E aí a gente começa a pensar nos nossos principais processos. Qual que é o nosso principal processo aqui? Solicitar um estimate, ou seja, solicitar um orçamento para a nossa corrida. Beleza, então eu vou pegar minha setinha aqui, bonitinha, e vou colocar aqui, aqui no meio. Request, estimate. Tá? Ou seja, o usuário está solicitando um orçamento. Legal? Quando o usuário solicita um orçamento, ele precisa, né usuário solicita um orçamento, ele precisa saber quem é o usuário, que sou eu, tem que passar a localização e o destino aqui para mim. No requisito está escrito assim para a gente. O passageiro pode solicitar uma nova corrida, informando uma localização de origem e destino e receber um valor estimado ali da corrida. Então, aqui está a minha solicitação. Agora, a gente vai começar a ter que pensar como é que essa parada funciona por dentro do nosso sistema. Bom, se eu vou fazer uma estimativa, eu posso fazer uma estimativa baseada sempre em algo que vai virar uma corrida, então eu posso, tá, e depois a gente pode mudar e reinterpretar isso de outra forma, mas eu posso chegar aqui por exemplo, e falar o seguinte olha, eu tenho um serviço aqui de ride, esse serviço ele vai cuidar e gerenciar de forma geral todas as minhas corridas, independente nesse momento se esse cara é um passageiro ou se ele é um motorista. Então, eu vou fazer esse cara, ele vai bater aqui para mim, bonitinho. Mas, esse cara, de alguma forma, vai ficar registrado isso em algum lugar. Então, nesse momento, se eu quiser, apenas pra representar, porque eu não quero ir nesse momento em detalhes de banco de dados, eu simplesmente posso chegar e vou falar o seguinte, olha essa solicitação de uma nova ride vai cair aqui pra mim tá, mas o seguinte agora que eu tenho a minha solicitação que eu tenho de orçamento e que eu vou trabalhar aqui, o que que eu vou a minha solicitação, que eu tenho de orçamento e que eu vou trabalhar aqui, o que eu vou fazer? Eu preciso, de alguma forma, fazer o quê? Ver aonde o meu passageiro está e os motoristas que estão perto dele. Eu tenho que ter um matching de rider e drivers nesse momento. Então, o que eu posso fazer aqui? De rider e drivers nesse momento. Então o que eu posso fazer aqui? Eu posso ter um cara aqui chamado de ride matching, por exemplo. Vocês estão conseguindo ler bem, galera, o que eu estou escrevendo aqui? Está ok aí para todo mundo? Show de bola. Então eu tenho um ride matching. Esse ride matching, ele vai ter que saber o que ele vai ler pra ele fazer um match de algo. E agora que aquele momento que você fala, e que se você publicar só esse corte no Instagram, no LinkedIn, no YouTube, vão falar que eu sou o pior cara do mundo pra fazer qualquer tipo de system design. Mas vocês vão entender o que eu tô querendo dizer. mundo para fazer qualquer tipo de sistema de design, mas vocês vão entender o que eu estou querendo dizer. Esse cara, ele precisa de alguma forma de acessar os dados dessa ride. Para dizer que eu estou lendo dados, prestem bem atenção. Eu estou fazendo um apontamento do banco de dados daqui para cá. Eu não estou querendo dizer nesse momento que eu estou compartilhando um banco de dados. O que eu estou querendo dizer nesse momento que eu estou compartilhando um banco de dados o que eu estou querendo dizer é que eu preciso do dado que foi registrado de uma ride pra eu fazer um matching tá? como a comunicação vai ser feita e quais bancos de dados a gente vai usar e etc a gente vai falar amanhã mas o que eu estou querendo dizer aqui é mostrar muito mais fluxo nesse momento tá? e nesse momento eu tenho um ride matching. Quando eu faço um matching de um ride, o que vai acontecer aqui do lado? Eu vou ter provavelmente o meu o cara que tá solicitando, como que eu pinto isso aqui? O cara que tá solicitando o motorista e eu tenho aqui um monte de eu tenho aqui um monte de motorista agora aqui comigo. Aqui eu tenho um monte de motorista e eu tenho aqui um monte de eu tenho aqui um monte de motorista agora aqui comigo, aqui eu tenho um monte de motorista em volta desse cara cada motorista desse tem uma distância aí provavelmente ele deve ter um algoritmo muito complexo que ele fica vendo a distância de cada um desses caras para cada motorista, aí ele consegue ter o ETA, o Estimated Time of Arrival, e aí ele consegue, baseado nisso aqui, falar, são esses caras, baseado nesses caras que eu tenho, eu preciso gerar uma forma de orçamento para esse cara. Então, agora que eu tenho os caras que eu sei que estão em volta de mim, o que eu vou fazer? Eu vou simplesmente fazer o meu orçamento. Eu vou colocar aqui um serviço de cálculo de corridas aqui pra gente. Novamente, tá? Somente pra gente ter clareza que tudo isso tem um banco de dados. Né? E provavelmente esses bancos de dados, eles são bem diferentes, cara. Esse banco de dados aqui, ele é extremamente focado em geolocalização. Né? É um banco de dados totalmente diferente provavelmente do que o banco de dados desse cara, o banco de dados desse cara aqui, depois a gente pode falar dos tipos de bancos de dados e os algoritmos que esses bancos de dados utilizam como quadrantes só como spoiler pra vocês saberem galera vocês sabem como é que o Uber consegue fazer essa aproximação? Vocês tem mais ou menos uma ideia de como ele trabalha? O Uber, cara, só por curiosidade Depois eu posso falar disso amanhã Ele faz o seguinte, cara Ele tem Ele cria células Deixa eu mudar a cor desse cara Imagina que eu tenho a cidade inteira dentro de cada cidade ele cria células pra conseguir dividir a geolocalização e os servidores e os bancos de dados eles ficam focados em cada um nas suas células aqui ó e dentro dessas células eu tenho o que? Colocados em cada um nas suas células. Aqui, ó. E dentro dessas células, eu tenho o quê? Eu tenho um monte de motorista por aqui, ó. Eu tenho um monte de motorista nesse pedaço. Eu tenho um monte de motorista nesse, um monte de motorista desse. E eu tenho o cara que quer a corrida que tá aqui, ó. E eu tenho motorista desse lado. Eu tenho motorista desse lado, eu tenho motorista desse lado. Por que isso ajuda? Porque na hora que eu falo que o cara está aqui, ele fala, agora eu vou rodar um poder computacional e eu vou ter máquinas que estão especializadas em resolver problemas só nesse quadrante. E daí ele resolve só esse problema e ignora todo o resto do mapa. Porque se ele tivesse que ficar tentando processar tudo, dava pra ver que ia dar ruim. Então eles fazem separações, se fossem hexágonos, eles chamam de células, e essas células vão separando todas as localizações, quebram, e daí esses agrupamentos é onde eles começam a fazer o match em volta desses caras, tá? Só pra nível de curiosidade, tá? E aí, no final das contas, eu tenho a minha a minha FAIR, né? O meu orçamento. Provavelmente depois que eu tenho um orçamento, eu vou ter que notificar o usuário. E depois que eu notifico o usuário é deixa eu colocar esse cara aqui E depois que eu notifico o usuário... Deixa eu colocar esse cara aqui dessa cor. E depois que eu fiz essa notificação, provavelmente eu vou mandar esse cara aqui de volta, que vai voltar de volta. Perceba, galera, que não estou usando nada de mensageria. Vocês estão percebendo isso, né? Ok? Falem sim, Wesley, por favor. Só para eu sentir que eu não estou sozinho, tá? Eu sou um cara carente, entendeu? Então... Sim, Wesley, por favor. Sim. Por favor. Eu me senti um cara mais... Estava bloqueado, hein? um cara mais bloqueado eu sou um cara ignorado nesse lugar, não adianta só pra tirar só porque você é incapaz no caso nós estamos falando de uma requisição síncrona a gente vai ter sincronicidade nesse ponto, certo? Então, o que eu estou querendo dizer é que tudo que eu estou colocando aqui, nesse momento, eu não estou preocupado com o formato de comunicação. Eu deveria estar... É apenas uma abstração. É uma abstração de propósito, porque amanhã a gente vai falar sobre os formatos de comunicação. E daí a gente vai mudar tudo isso aqui. Fez sentido o que eu estou dizendo? Porque assim você transmite o negócio. Então a ideia é transmitir o negócio. Pode colocar num guardanapo de papel, que aliás foi assim que foi feito o Uber. E aí a partir disso você consegue ir para cada comunicação, cada etapa, cada peça de software, você consegue detalhar. Nesse caso aqui eu preciso de uma comunicação que é assíncrona, mas aí você vai debulhando. Mas de uma forma, para uma pessoa de negócio, principalmente que você vai, às vezes, ter que apresentar, fica mais simples de mostrar o que é a ferramenta passiva. O que eu estou tentando fazer agora aqui é fazer com que esse desenho reflita o que a gente colocou ali nas APIs ali em cima. Depois faz um refactor disso aí, né? Aí a gente vai refatorar, porque não é assim. Todo mundo sabe que do jeito que a gente está colocando aqui, isso jamais escalaria. Então, acho que esse é o grande ponto que eu estou querendo colocar hoje aqui. Amanhã vai ser o dia que a gente vai fazer isso de uma forma decente, tá? Mas o ponto importante que eu tô trazendo aqui é como que eu consigo fazer com que eu cubra os requisitos que eu acabei de falar. Fechou? A gente tem... Tem que considerar a disponibilidade e a coerência, no caso, né? A consistência. Não tô pensando nisso nesse momento. É aquilo que eu falei, eu estou deixando um monte de requisito não funcional do lado, uma observação e é importante colocar galera se vocês tiverem uma entrevista de system design não façam dessa forma vocês já vão fazer da forma com os formatos de comunicação tá, eu só a única coisa que eu estou deixando claro é que eu vou fazer aqui, porque a gente tem três dias de evento pedaço por pedaço. Então, hoje eu não estou preocupado com comunicação. Eu estou preocupado com o design, os requisitos e com o fluxo de como as coisas funcionam. Amanhã, a gente vai se preocupar como que a gente faz essa parada escalar, porque isso que a gente está colocando, se esse sistema ficar fora do ar, o sistema inteiro cai. Já era. Foi pro saco essa solução. Entendeu? Ué, ficou show, porque você está dando uma visão macro e depois vai ser detalhada. Então a gente consegue ter uma visão rapidamente e vendo que está coletando os requisitos conforme estava na especificação. Ficou show de bola. Eu conforme estava na especificação. Ficou show de bola. Eu acho que está claro, né, galera? Solicitei a ride, depois disso eu faço o matching com o motorista, depois eu calculo o preço e notifico o cara aqui que o preço ficou tanto para ele. Parabéns à turma da sala 62, hein? A gente passou pertinho disso aí, ué. Ah, aí, ó. Os caras, show de bola. Depois me mandem a parada. É, Wesley. Opa. Só queria dar meus 10 centavos aí de contribuição aí desse esquadrante que você comentou, né? Na Localiza a gente usa bastante isso aí, que a gente usa o GeoHash, né? E o Redis, ele já tem infra ali pra trabalhar em cima de geolocalização utilizando georash, né? E, cara, é bizarro o processamento. É outro nível, né? É outro nível de como que trabalha, né? Na teoria ali, num sistema sei lá, de estudo, você vai fazer um cálculo ali de Ravenstein, fazer cálculo de entre lat e long, né? Ele não, ele converte o lat e long pra pra georash, que depende da precisão, né? Seis ou nove dígitos, e o Redizzer trabalha, cara, fenomenal com esse georash, né? Cara, no final do ano passado, a gente ia ter uma uma live com o Ricardo Ferreira da Redis a gente vai remarcar com ele ele teve um problema de saúde com o filho inclusive no dia da live, ele não pôde vir ele trabalha na Redis mas ele trabalhou na Confluent ou seja, ele é especialista em Kafka também ele trabalhou na AWS ele trabalhou na Elastic então é um cara de super alto nível, ele é o cara um dos caras que eu mais admiro ali, técnica, meu cara é bom pra caramba e ele hoje ele tá na Redis, cara e é incrível a quantidade de coisas que o Redis faz e a gente nem tem ideia ainda mais com o relicenciamento que aconteceu no Redis agora, tá? Então ó, mais um motivo da galera que quiser participar do NBA, preenche o formulário pra conseguir ter esses tipos de aula, tá, galera? Só pra vocês saberem, aproveitando o jabá já aí. Seguinte, vamos continuar. Qual que é o outro passo? O passageiro precisa confirmar que a corrida vai começar, legal? Então, eu só vou mudar de cor aqui, pra não ficar confuso. E normalmente, pessoal, eu gosto de numerar passo 1, passo 2, passo 3, passo 4, pra quem olhar conseguir ter clareza do fluxo que está acontecendo. Eu não vou fazer com passo, mas eu vou mudar a cor do requisito aqui. Depois a gente melhora isso amanhã. Então, o lance é o seguinte. Nesse momento agora, eu tenho o ride confirmed. Deixa eu pintar isso aqui de verde. Nessa setinha que tá voltando pro rider. Não daria pra colocar um receive price? Alguma coisa assim? Cara... Não é necessário. É que eu tô querendo escrever menos, porque vai ter um monte de seta isso aqui ainda. Entendi. Vai ter um monte de seta. Quando a gente conseguir fazer o sistema design com as comunicações, com as filas, com tudo bonitinho, a gente não vai ter tanta seta dessa forma. Então, é capaz de a gente conseguir fazer isso melhor mas eu vou colocar aqui rider ride confirmed ou seja, o rider confirmou a corrida e aí o que vai acontecer na hora que esse cara confirma a corrida a gente vai fazer o seguinte, a gente vai mandar essa parada pra corrida, a corrida vai, obviamente, ficar novamente registrada no banco de dados, que houve essa mudança ali pra gente, aí a gente novamente vai cair no matching que agora esse matching vai ser o de verdade, que agora vai ser o momento onde nós vamos apontar realmente quem é o motorista. Ué, a gente só criou a ride, no caso, né? Só persistiria a ride depois da confirmação que realmente haveria corrida, para não ficar criando ride à toa, entendeu? Então, tem duas formas de pensar. Essa forma sua, que eu concordo, mas tem outra forma de pensar. Eu posso criar uma ride e essa ride ser cancelada ou eu posso criar um orçamento, que é mais ou menos como eu coloquei aqui na FAIR, que se não for aceita, não cria ride. Então, tem essas duas formas. Eu posso criar uma ride que não for aceita, não cria ride. Então, tem essas duas formas, tá? Eu posso criar uma ride que não é aceita e ela cancela, ou eu posso criar um orçamento, né? Uma fair estimate que não é aceita, daí não cria ride, tá? Tem essas duas formas, tá? Tem essas duas formas e, na minha opinião, tá super ok se alguém der essas duas soluções pra mim, é algo que faz sentido, pelo menos, tá? Então aqui nesse momento a gente já vai saber quem é o driver agora, porque ele vai fazer um match e vai saber o driver. Eu não preciso em tese, mas cai no micro serviço de preço, porque o preço já foi dado, né? Então o Uber já prometeu aquele preço ali. Então, nesse momento talvez, tá? Eu não quero entrar nesse detalhe, ele cai em algum momento no preço pra dar o preço promotorista de quanto que ele vai receber, tá? Não tá escrito na especificação, não quero pensar sobre isso. Deu vontade, ó. Olha só, eu já tô com comi... Eu que escrevi os negócios, eu fiquei com vontade de botar. Mas, não vou, tem que segurar a galera a vontade, tá então depois que eu tenho um ride matching aqui pra mim né, e o cara aceitou partindo desse princípio que ele aceitou o que que vai acontecer eu vou mandar uma notificação para o meu querido cliente que a corrida iniciou e que ele tá com o meu, que vai um motorista falar com ele. A gente sabe que na prática o Uber é diferente, né? Ele começa procurando o motorista, né? E etc. Mas no final das contas é na hora que tá no ride matching, né? Ele fica lá no app, ah, estamos procurando o motorista, é na hora que tá no ride matching, né? Ele fica lá no app, ah, estamos procurando o motorista, é porque ele tá aqui. Na hora que ele encontrou, ele manda a notificação, opa, o Pedrinho vai te buscar. Mas, o que que acontece aqui pra mim? Nesse momento, aqui que o ride tá confirmado, obviamente que há o processo em paralelo, onde eu tenho o driver aqui, correto? É o Wesley. Mas, nesse segundo momento aí que ele confirma o ride, ele não teria que passar de novo pelo cálculo, porque pode ser que esse segundo motorista esteja em um local diferente do primeiro, que foi usado por cálculo inicialmente. Pela regra como é hoje do Uber, pelo menos aqui nos Estados Unidos, e como tá ali é eu mandei um orçamento o preço é tal esse é o preço que eu vou pagar ele não fica mudando o preço o tempo inteiro, a não ser que você demore pra confirmar entendeu? eu recebi um orçamento é esse hoje, não sei como é que tá no Brasil, mas aqui nos Estados Unidos você pediu o coisa, ele falou que aquele valor demorou 10 meses para achar o motorista, o preço é o mesmo é, inclusive, se não achar o motorista X, ele te passa um do Comfort do mesmo valor para manter o preço mas dependendo da corrida eu acho que na verdade o valor muda se o usuário muda a localização ele pode estar caminhando e esse valor atualiza. Na realidade... A vontade dos motoristas também, né, que ficam cancelando lá até que o preço suba e eles acham que o preço está ok para a quilometragem. Está rolando aqui no Brasil. No Brasil, ele sim, ele reserva um valor, naquele valor ele vai te fornecer o serviço mas o serviço pode mudar ao longo da corrida e quando você muda quando você pede automaticamente pra trocar também de categoria ele muda o valor, é isso aí nesse nosso caso você pode ter mudança nesse nosso caso isso aí não tá no requisito vou terminar a aula tem criança chorando tem a perreia aqui eu sempre pensei que o cálculo era baseado na origem e no destino, independente de motorista mas é, basicamente é isso, a não ser que vamos lá vamos lá então vamos lá o que acontece, manda a notificação que foi confirmado e agora Vamos lá. Mas enfim. Vamos focar. Vamos lá. Então vamos lá. Então, o que acontece? Manda a notificação, né? Que foi confirmado. E agora, obviamente, o motorista, obviamente, nesse caso aqui, ele vai ter que... A gente vai ter que solicitar também para o motorista, né? Que essa... Que ele vai poder aceitar ou não essa ride. O que vai acontecer? Nesse momento, o motorista, o que ele vai poder fazer? O motorista vai poder falar que... Ele vai poder... Opa! É verde aqui, só para não confundir o nosso fluxo. Nesse momento aqui, o que vai acontecer com o nosso motorista? Ele vai ter a confirmação do driver, ou seja, ride confirmed também, ou seja, o driver falou confirmado aqui para mim e eu vou trabalhar com isso. Então o que o motorista vai fazer? Ele bateu, vai cair no serviço do ride lá, falando que agora a gente tem esse novo motorista, vai guardar no banco de dados, falando que é um motorista, a gente não precisa mais de matching, o que vai acontecer? O ride vai notificar que a... o serviço de notificação e provavelmente nesse momento o usuário, ele também vai ser notificado que fulano tá indo te buscar, tá? Baseado nesse cara aqui, que é o que aconteceu. E agora, a gente tem um outro ponto que pra gente é importante, né? Que é o quê? Os dois caras, eles precisam, né? Ter a localização deles. Mas pra que eles tenham a localização, eles precisam ter uma coisa em comum aqui nesse caso, né? Eles têm que executar uma operação de update location. Certo? Então esse cara, ele vai ficar mudando a localização dele o tempo inteiro, né? e quando ele mudar essa localização essa localização ela pode ser persistida tanto pra ride falando onde é a última versão onde essa localização desse cara tá mas, aqui não é o local ideal pra ficar traqueando pedaço por pedaço essa localização desse cara tá, mas aqui não é o local ideal pra ficar traqueando pedaço por pedaço da localização a gente precisa ter diversos pontos de localização, e é por isso que nesse momento, eu aqui né, colocaria facilmente um location a service aqui que vai ficar responsável exatamente por coordenar tudo que for de recebimento de localização de todo mundo. Então, nesse caso aqui, eu pegaria todos esses dados aqui de localização, e não necessariamente do rider e mandaria direto para o location. A gente vai falar isso porque a gente vai falar de fila amanhã, né? Na realidade, são dois caras interessados na mesma informação. Então, esse cara vai ficar mudando a localização dele o tempo inteiro, da mesma forma que o nosso querido driver, ele também vai ficar mudando a localização dele, o update, location dele, o tempo todo aqui pra gente. Galera, com isso, se vocês perceberem e prestar bem atenção, a gente matou todos os requisitos que a gente colocou. Tá? A não ser a notificação da localização atual, de tempos em tempos, né, da onde cada cara está. Então, basicamente, a gente tem essa pegada aqui, né, isso aqui vai se espalhar tanto pro motorista quanto pro passageiro, né, que é no final das contas a localização desses dois caras. Tá tudo rabiscado, tá feio, tá difícil pra entender separei por cor exatamente pra mudar pra cada isso representar um endpoint, no final das contas apesar desse gráfico e essa parte caótica como tá sendo mostrada aqui de uma forma geral não pensando nos requisitos não funcionais, esse cara está conseguindo implementar o que a gente está colocando de uma forma mínima. Obviamente deve ter um trilhão de serviços a mais que o Uber usa, um trilhão de serviços mesmo a mais do que a Uber usa. Mas aqui começa a fazer um pouco mais de sentido sobre aqueles três pontos que a gente fala. Eu tenho a corrida, eu faço o médico driver, eu consigo calcular o orçamento, eu consigo notificar e eu consigo fazer o gerenciamento o tempo todo da localização desses caras. O ponto é, a cada quatro segundos eu mando a localização aonde eu tô. Cara, esse cara consegue aguentar um monte de requisição a cada quatro segundos de um milhão de corridas. Então requisição a cada 4 segundos de um milhão de corridas né, então a gente começa a perceber que isso aqui não pode ser um simples serviço que recebe localização pra salvar, a gente vai precisar de muito mais tecnologia e ferramentas pra gente fazer isso concordam comigo né é bem óbvio isso que eu tô dizendo então, qual que é o nosso objetivo principalmente amanhã, galera? A gente vai explorar bastante formatos de comunicação. A gente vai falar de comunicação síncrona, comunicação assíncrona, a gente vai falar de REST, GRPC, GraphQL, a gente vai falar de WebSockets, Server Center Events, a gente vai falar de mensageria, a gente vai falar de RabbitMQ, a gente vai falar de Kafka, a gente vai fazer comparativo dos dois, a gente vai falar sobre outros serviços e a gente vai refazer esses caras aqui de uma forma mais decente, onde a gente consiga garantir mais, mais resiliência, conseguir fazer com que aqueles requisitos não funcionais, eles comecem a entrar e participar de todo o processo fez sentido pra vocês? fez sentido galera? galera, alguém tá com alguma dúvida do que eu acabei de de colocar? pra gente encaminhando pro final? não, foi super sentido. Não, tranquilo. Fez total sentido. Tá bom. Eu acho que deu pra pegar a ideia, né? Deu bastante, pô. Eu acho que, não tô com certeza, mas acho que faltou só nas entidades ressaltar lá o driver, né? certeza, mas acho que faltou só nas entidades ressaltar lá o driver, né? Acho que na lista lá faltou. Cara, eu acho que tá lá sim, viu? Se não tiver, come bola. Ah, não. Tá faltando o driver mesmo. Tá faltando o driver. Tá faltando o driver. Tem o driver, tá, pessoal? Muito obrigado. Tá faltando o driver tá faltando o driver tem o driver, tá pessoal? Muito obrigado tá faltando o driver galera a grande pegada é o seguinte, tá? são três dias vou ficar muito feliz se todo mundo poder amanhã voltar e a gente terminar eu acho que amanhã é um dia um dos dias mais importantes, inclusive, porque eu acho que a coisa que deixa mais complexo qualquer tipo de sistema, e é o que consegue definir, na maioria das vezes, se um sistema vai conseguir escalar ou não, é a comunicação. Comunicação entre sistemas é uma das coisas mais complexas que tem porque no final das contas é o que mantém a resiliência, é o que mantém os caras no ar, mas tem momentos que precisa ser síncrono, tem momentos que precisa ser assíncrono porque você não consegue trabalhar então pessoal participem de amanhã, tá? Vai ter bastante coisa mesmo pra conseguir trabalhar. Novamente, eu peço aí pra vocês, preencham o formulário, eu vou até compartilhar aqui com vocês, quer ver? Um QR code, só ver uma coisa aqui. E eu preciso também... Tá, deixa eu compartilhar isso aqui, ó. Escanei isso aqui, galera. Conseguiu compartilhar? Ou não foi? Está compartilhado já. Vocês estão conseguindo ver um QR Code? Estão, né? Galera, escanei esse QR Code tá, vamos bater um papo porque com certeza eu não tenho dúvidas galera, que a gente consegue dar uma boa guinada aí pra vocês em 2025 e isso que a gente tá mostrando nesses 3 dias aí, é a ponta do iceberg do que normalmente a gente consegue trazer e ajudar vocês e não só comigo, né? Na realidade, com pessoas que são especialistas em diversas áreas, em muita coisa, né? Então, a gente está falando de banco de dados, cara, eu não sou especialista em banco de dados, mas eu conheço um cara que dá aula para a gente, que ele é o cara do banco de dados, que trabalhou com tudo, hoje em dia trabalha na MongoDB, então vale muito a pena vamos marcar um bate-papo entre em contato com a gente com certeza a gente consegue chegar numa situação aí que vai conseguir fazer sentido pra você fechou? e por último e não menos importante galera deixa eu parar aqui de compartilhar. Parou o meu compartilhamento, né? Foi. Parou o meu compartilhamento. Ô, Leonan, cola, por favor, o link da pesquisa. Antes de a gente fechar, pessoal, a gente precisa muito de saber o que vocês acharam nesse primeiro dia. É a primeira vez que a gente está fazendo esse evento, com bastante gente acessando o Zoom ao mesmo tempo, separando em telas e etc. A gente quer melhorar, a gente quer olhar o que vocês estão achando, inclusive para amanhã, já tentar fazer coisas melhores. Então, o Leonan está postando aí no chat pra vocês, tá? Uma pesquisa, cara, é três cliques, tá? Vocês vão ajudar a gente pra caramba preenchendo isso. É meia dúzia de clique, a gente consegue pegar o feedback de vocês e a gente já consegue trazer melhorias pra amanhã, pra tornar a sessão mais legal, mais agradável aí pra todo mundo. Fechou? então pessoal cliquem, preencham a pesquisa assim que vocês terminarem a pesquisa, vocês levantam não é levantar a mão, dá o joinha ali bota um joinha só pra gente saber que rolou aí o Leon não conseguiu colocar ali tá, se puder só dá um joinha tá e daí só pra vocês saberem, tá a gente vai correr da forma mais rápida possível pra pegar essa sessão que demorou quase 3 horas editar e subir na nossa plataforma pra quem perdeu ou não pôde assistir até o fim, ou teve problemas poder assistir, pra que amanhã à noite não fique perdido. Mas essas aulas, elas vão ficar disponíveis só até o final dessa semana, e depois elas vão ficar disponíveis pra quem são os nossos alunos ali do MBA, tá? E daí você vira aluno do MBA e você vai ter acesso de qualquer forma, tá? Mas somente pra vocês saberem, né, quem perdeu algum pedaço, alguma coisa, a gente vai correr pra disponibilizar o quanto antes pra vocês na plataforma. Todo mundo aí tá com acesso na plataforma, né? Quem não tá com acesso na plataforma é só acessar plataforma.fullcycle.com.br Entra com o seu e-mail e senha. Se você não sabe a senha, dá um esqueci minha senha. Você vai ter acesso às aulas que a gente colocou. Maravilha? E daí, provavelmente, lá vai estar disponível a gravação dessa... da sessão que a gente teve hoje. E a gente vai editar. Oi da sessão que a gente teve hoje. E a gente vai editar. Wesley. Oi. Para mim aparece apenas o curso do Go Expert. Esse curso aí dessa Tech Week não aparece para mim, não. Cara, você se inscreveu no Tech Week? Oficialmente? Fiz a inscriçãocrição é no grupo do WhatsApp, né? Não sei se tem algum outro local pra fazer a inscrição. Cara, tem uma página. Ô, Leonan, passa a página do UFC Tech Week pra ele. Tá aí, pessoal. Quem não tá com quem não tá com acesso ao Tech Week, o Leonan cola o link. quem não tá com acesso ao Tech Week o o Leonan cola o link, é só fazer o cadastro ali, preencher aí o sistema já vai liberar o acesso pra vocês, tá? você vai receber o acesso ali por e-mail e daí vai ficar disponibilizado na plataforma aí pra você fechado? tá, então cliquem nesse link, se você tem acesso à plataforma e não tá aparecendo essa matéria aí do Full Cycle Tech Week for Seniors, clica nesse link, você cadastra, é esse cadastro que faz liberar o curso na plataforma pra vocês, tá? Maravilha, meu povo. Então, galera, muito boa noite. Opa, pode? Em dois minutos. Cara, só pra vocês saberem, sabe o que eu vou fazer saindo daqui agora? Adivinha. Eu vou correr 14 quilômetros. Deixa eu só tirar o... Faz isso não, velho não, pelo amor de Deus. Eu estou treinando para uma meia maratona, que eu vou ter que fazer. Faz isso daqui a pouco. Faz isso daqui a pouco. Opa, um ligado, manda ver. O curso do EMEI, ele é mais avançado que o de liderança? De Dev e a Tech Lead? Ou ele é distinto? Cara, é bem diferente, tá? Porque o de Dev e a Tech Lead ele tem coisas técnicas, mas muitas das coisas técnicas são pontos de alto nível, um mais alto nível, né? Porque ele tem um foco muito mais em fazer com que o líder entenda bem daquelas tecnologias, tem um nível de profundidade legal, mas também que ele consiga fazer criação de times, conseguir trabalhar com o board, desenvolver soft skills, não ser enrolado pelos outros caras, por isso que a parte técnica é bem importante e tudo mais. outros caras, por isso que a parte técnica é bem importante e tudo mais. Já o MBA, aí eu digo que ele é uma parada mais pesada no aspecto, porque a gente separa ele como arquitetura de solução, que é uma disciplina completamente, entre aspas, diferente de entender arquitetura de software, aí ele pega DevOps e SRE, e daí ali tem muita coisa, desde prática de DevOps infraestrutura como código e etc e a parte de soft skills, que cara assim, é um módulo absurdamente fantástico entendeu? Então o MBA ele é separado, ele é mais técnico mas ele também não é um curso de programação, entendeu? Então o MBA não é um lugar que você vai querer ir pra aprender Go sacou? mas ele é um lugar que você vai aprender a fazer System Design vai ser um lugar onde você vai aprender Solid, você vai aprender Arquitetura Hexagonal, você vai aprender Clean Code, você vai aprender todas essas coisas mas num nível ainda mais alto porque a ideia ali não é te ensinar a programar, não é uma escola de programação, você está fazendo um MBA. A ideia é que você tenha cada vez mais visão de alto nível e quando você consegue juntar conhecimento de arquitetura de solução, isso que eu vejo que muitos devs acabam não conhecendo muito bem, e você alia isso com arquitetura de software, que às vezes também tem dev que faz as coisas muito na intuição, mas não tem aquele conceito firmado o porquê que ele tá usando aquilo naquele momento. Tipo, porquê que você usa repositório? Porquê que um repositório retorna uma entidade e não um objeto de valor? Ou um DTO? Saca? Então, esses tipos de coisa é o que acaba diferenciando muito na hora que você vai arquitetar um sistema. Porque você, o que falta muito pra galera é fundamento. Porque saber programar, galera, hoje em dia, o chat GPT programa pra você. Entendeu? Agora, programar, entre aspas, do jeito certo e o jeito certo é sempre dependendo do contexto ainda onde você tá é diferente, porque eu já vi muita gente, sei lá falando de sei lá, de um padrão repositório o cara vai lá e fala assim eu vou buscar um repositório e passo os parâmetros que ele quer receber cara, um repositório não recebe parâmetros ele recebe uma entidade. Porque ele trabalha com agregados, no final das contas. Então, aí começa... Você usa um repositório, mas não é um repositório. Daí você usa um objeto de valor que era para ser um DTO. As coisas começam, falta fundamento. O que a gente sempre tenta trazer são esses fundamentos muito claros, porque você consegue realmente ter clareza do que você está fazendo. Então, a gente consegue perceber que estar passando daquela ideia só de programar é resolver problema. Você tem um problema, aí você tem que ter uma estratégia e a parte tática para você poder resolver o problema. E isso aí faz uma diferença tremenda. Não é só sair escrevendo de qualquer maneira. E cara, além de resolver o problema, não é só isso. Sabe o que que é? A parte pior ainda não é o resolver problema. Porque de uma forma ou de outra, mesmo no Hadouken, na programação Force, etc. Você acaba resolvendo o problema o ponto é que quando você está em uma empresa grande e quando você resolve o problema de uma forma ruim o software que você está construindo hoje ele tem que durar 10 anos, senão ele foi prejuízo para a empresa como você consegue fazer um negócio que vai durar 10 anos exato exato a diferença que vai durar 10 anos. Exato. Exato. A diferença de um dev sênior pra cima é que o cara não tá pensando em fazer esse software pra fazer aquele negócio funcionar agora. Ele tá pensando nesse software pra ele funcionar ao longo dos anos e que cada vez ele consiga minimizar a complexar ao longo dos anos e que cada vez ele consiga minimizar a complexidade ao longo do tempo. Porque ao longo do tempo a complexidade aumenta e isso é lei. O ponto é como você minimiza isso. Então, eu acho que o que a gente traz muito de arquitetura de software no MBA é essa visão. Porque, cara, programar, meu amigo, entendeu? Você aprende de graça. Antes eu tinha uma visão de que a arquitetura era separada. Hoje eu consigo compreender que, pô, se você começar com uma arquitetura hexagonal, por exemplo, que é o basicão, depois você pode ir aprofundando e chegando até, se houver necessidade, até num DDD, onde você vai ter que aplicar uma série de outras coisas. Cara, eu vou até mais longe, tá? No MBA a gente tem uma um módulo que, inclusive, tem a parte de System Design, mas também entra um pouco na arquitetura de software, que foi do Fernando da Google. Ele que deu essa aula, eu achei fantástica e eu trabalhava nessa, usando isso e ele pontuou eu bastante isso na aula, que é algo que a gente chama de middle out. Alguém já ouviu falar em middle out? Não, middle out não. Cara... De dentro pra fora, seria isso? Mais ou menos. De meio, do meio pra fora. É, do meio pra fora, isso, é. Olha só, seguinte, vocês concordam comigo que nas aplicações tem lugares que são muito críticos e tem lugares que são menos críticos. Vocês concordam comigo isso? Correto. Bem óbvio, certo? Qual que é o maior problema na hora que você vai construir uma nova aplicação? Eu falo, eu vou usar DDD, vou usar Clean Architecture, vou usar arquitetura orientada a nuvem, sei lá, vou usar arquitetura orientada ao Python. O nome que quiser da arquitetura que inventarem hoje. A maior hype. Qual que é o problema? O problema é que se você vai começar um projeto, sei lá, vou usar, estou dando um exemplo, arquitetura hexagonal. Tá? E daí eu tenho o meu cadastro do usuário. Certo? Que é um crude. O que a gente tende a fazer? A gente bota esse crude na arquitetura hexagonal. Aí, o que acontece? Aí eu tenho um cadastrinho de status. Aí eu boto o cadastrinho de status na arquitetura hexagonal. Aí eu tenho um negócio... Aí tem o core do sistema. Aí você faz esse core do jeito bem feito com a arquitetura hexagonal. Beleza. Sabe qual que é o grande problema aí? Que você gastou um puta tempo com uma puta complexidade às vezes pra fazer um crude. E esse crude vai mudar pra caramba, ainda mais se o software tá no início. O que que é o middle out? É você usar múltiplas arquiteturas dentro do mesmo software. A parte crítica, é, a parte crítica do software, o meio dele, o coração dele, você faz da forma mais foda possível, porque essa parte precisa estar protegida. Sim, sim. O problema é que a gente tem dois extremos. Ou a gente faz tudo sem vergonha, desde o crude até o coração, ou a gente faz desde o crude, da forma mais rebuscada, até o coração da aplicação. O ponto é que a gente não precisa fazer isso. A gente pode fazer as extremidades da aplicação, que tem menos regra, tem menos complexidade, é menos crítica, de uma forma extremamente simplificada, e a parte do meio importa. A gente dá aquele gás pra fazer bonito. Tem até um livro que eu tava lendo sobre exatamente isso é um livro que o cara é de dotnet, mas ele fala isso agora eu me lembro, é um livro capa vermelha com uns desenhos, esqueci agora é pattern é um negócio assim muito legal, ele fala exatamente sobre isso que o cor tem que ser bem feito. Agora, o que não for tão importante, você não precisa demandar tanto esforço pra aquilo. E o que a gente mais vê... Fala a verdade. Quem nunca foi fazer uma arquitetura bem feita de um software, tudo fodidão, tudo bonitinho? E daí, se já que tá fazendo tudo bem, eu vou fazer tudo bem feito. E aí, o seu cadastrinho de categorias teve o mesmo nível de complexidade do que a regra de cálculo financeiro que vai manter a aplicação que é o real motivo que a aplicação vai funcionar. Quem nunca fez isso? Eu já fiz isso pra caramba, cara. Quando chegava no meio... Você trata o cadastro do sistema da mesma forma que você está tratando a parte mais complexa do sistema. É isso mesmo. E, cara, todo mundo cai nisso, mas conforme você vai chegando no momento da carreira, você fala, cara, o que é importante desse sistema? Então, o que é mais importante eu vou fazer bem feito. O que é menos importante, não é que eu não vou fazer bem feito, mas eu não vou botar tantas camadas, tantas firulas, para algo que principalmente vai mudar. O coração do software é o que menos muda, porque é a área mais estável. E quanto mais estável ela é, mais bem feita ela tem que ser. As extremidades do software são as partes mais instáveis, elas mudam toda hora. Se você tiver uma dificuldade muito grande de mudar a extremidade, é diferente. Uma coisa é eu ter a minha mão e ter a minha unha, uma coisa é eu pintar a unha, eu mudo qualquer hora a minha unha, entendeu? Agora eu não posso fazer cirurgia do meu coração da mesma forma que eu pinto a minha unha. O nível de complexidade é muito diferente. O nome do livro é Patterns, Principles and Practice of Domain Driven Design. Cara, muito bom. Patterns, Principles... Quem que é o autor? É de um russo, não é? Deixa eu ver aqui o nome dele lá em cima. Coloca a capa do livro no vídeo aí, na câmera. A capa? Tá, peraí. É porque eu tô olhando ele. Aumenta aí que eu tenho que ir aqui no outro. É um livro de Domain Driven Design de capa vermelha? Eu acho que é. É Patterns, Principles and Practice of Domain Driven Design. Deixa eu ver se eu acho aqui a capa. Ah, do Scott... Acho que é Scott alguma coisa. Acho que é esse cara mesmo. Tá no chat já. Ah, beleza. Uma observação, tá? Já fazendo uma observação, tá? Só pra você que gosta de Domain Driven Design. Sabe quem dá aula no nosso MBA de Domain Driven Design? Eu vi lá. O Pão Verno, que escreveu o livro de capa vermelha do DDD. Ele dá aula também. Eu tenho isso também. Até a tralha toda, ué. Mas eu acho que a grande sacada de saber escrever software é o nível de maturidade pra conseguir tomar esse tipo de decisão, sacou? Sim, claro. Porque quando você é mais júnior, você quer fazer tudo com a mesma qualidade. E é até difícil você falar pra uma pessoa que essa parte eu não vou ter tanta qualidade, entre aspas, entendo o que eu tô querendo dizer com qualidade, como essa parte, assim, como assim? O sistema inteiro tem que ser bem feito, elelusive, é aí que ele pega o time com maior expertise e põe pra resolver o corre. Então, essa que é a grande sacada, galera. Agora, tomar essas decisões, são decisões que às vezes não são muito populares, entendeu? Como que eu vou falar pro cara, fazer um cadastro ali, não usando um padrão que tá no software, mas num outro pedaço vai usar um outro padrão? É, né? Eu acho que isso deixa a gente na necessidade que a gente tem de desacoplamento. Oi? Eu disse que eu acho que isso que você tá evidenciando só mostra pra gente quanto é importante ter um sistema com desacoplamento. Cara, é importante ter um sistema com desacoplamento cara, é importante o sistema de desacoplamento, mas eu vou até um pouco mais longe, cara eu acho que dependendo da extremidade, eu dou quase que, desculpe o meu português, um foda-se pro aclopamento, não tô dizendo que eu vou fazer mal feito, tá mas eu não vou ser tão pique com o acoplamento como eu vou fazer mal feito, tá? Mas eu não vou ser tão pique com o acoplamento como eu vou ser no core. Entendeu? Eu não vou criar 10 mil interfaces com 10 mil design patterns, com milhares de abstract factors e o caramba 4 pra criar um objeto que no final das contas vai me retornar um crude. No core eu faço isso. É, mas eu digo acoplamento entre as partes do sistema mesmo. Ah, com certeza. Então você dá liberdade para algumas partes serem menos funcionais. Eu acho que nisso, usando a mensageria, com as garantias de entrega que a gente tem, a gente consegue ter um equilíbrio muito bom frente à necessidade do negócio. Agora, o grande desafio de qualquer desenvolvedor sênior, tech lead, etc, é conseguir, eu vejo, passar esse tipo de visão pra outros desenvolvedores. Porque não é uma decisão fácil de você passar. O que você tá falando é que você não vai entregar o software com a mesma qualidade em todas as partes dele. E na real é isso. Mas, na prática, o que você está dizendo é eu vou proteger o meu domínio com arquiteturas mais adequadas e partes que não exigem tanta restrição e tanta proteção, eu posso fazer isso de uma forma um pouco mais leve. Esse tipo de decisão começa a ser aquela decisão quando você já está começando a ficar num momento mais maduro da sua carreira, porque o senso comum é você falar o que, no final das contas? Eu vou fazer um software, estou usando essa arquitetura, logo, pegue essa arquitetura logo, é essa arquitetura estou seguindo toda a arquitetura Wesley, é só você olhar um carro, compra o carro escolhe a cor que você quiser, depois você olha debaixo dele, vê que cor que é exatamente a parte de baixo ninguém se preocupou em pintar, porque não precisa estar pintado gostei, cara eu vou usar, em algum momento você vai me ver fazendo uma live e eu vou usar esse exemplo pintar, cara, porque não precisa estar pintado. Gostei, cara. Eu vou usar em algum momento, você vai me ver fazendo uma live e eu vou usar esse exemplo, só para você saber. Eu queria tirar uma dúvida aí. Eu queria tirar uma dúvida a respeito do system mesmo, do system design. Eu nunca participei de uma entrevista nessas Big Techs, sempre trabalhei em empresas de média e pequeno porte minha carreira inteira acaba como diz o Mano Deivinho eu sou crude maker, vamos dizer assim o pessoal é todo sistema de companhia mesmo ali, nada muito fora da curva e aí eu vi você desenhando essa parte inicial do System Design e tal, e eu sei que você vai complementar amanhã, porque tem que ser um pouco mais detalhado, mas aí a minha dúvida é, numa entrevista real, com base na sua experiência, eu começar com o fluxo e desenhar o fluxo e deixar isso bem claro, tendo essa visão de 40 minutos. Você não vai conseguir. Não vai. Você vai ter que fazer já direto. Posso só dar um testemunho, dizer assim? Claro. Eu participei de uma entrevista, seis dias atrás, para o Nubank. Eu rodei nessa parte. O System Design? É, porque eu fiz... Foi o que você falou, Wesley. Eu fiz a cagada de virar... Ah, faz um Kafka. Eu falei, ah, Kafka, então tá bom. Então vamos lá. Exatamente. Não tem o que fazer, cara. Não tem. Na hora que ele começou, ah, mas... Garantia de entrega, e a partição, e aqui, e não sei o quê, como que eu garanto pra... Aí já era. A e aqui, e não sei o que como que eu garanto pra a ordem das mensagens, aí já vai e detalhe, a solução que ele pediu pra eu escalar um negócio simples, era algo só pra gerar um arquivo CSV passar pra uma credora qualquer e ela retornar, qual que era os caras que tinham limite ou não mas eu fui lá, quis meter o carro ficando no meio quis ser bonitão lá quanto mais simples, melhor. O lance é o seguinte... Eu tinha passado. Oi. Eu acho que tem que ser arqueológico de tecnologia no system design. Você não pode falar de tecnologia nenhuma. Não fala. Não, você vai falar. Mas só no core, mas se você for trabalhar com o Kafka, tipo, eu não sei definir qual mensageria é melhor aqui. Se é o Kafka, se é o RabbitMQ, o CPE, alguma coisa assim. Então, o que acontece é o seguinte, tá? Quando você tá em Big Tech, muitas vezes você vai aplicar pra uma vaga, sei lá, de sênior. Mas, na real, na Big Tech, o que esses caras fazem? Eles não ficam muito só pensando em qual cargo ou vaga que você está. Ele vai fazer o sistema de design com você e, baseado nas suas respostas, ele vai falar, você não é sênior. Ele vai falar, você é pleno. Aqui dentro, pra gente, você é pleno. Por conta da sua resposta. Por exemplo, você falou, aqui vai um sistema de mensageria e tudo mais. Com certeza, você falou o sistema de mensageria, ele vai virar e falar assim, cara, qual sistema você usaria aqui? Você não vai escapar dessa. Você botou mensageirinha, o cara vai perguntar qual. E daí você fala, ah, poderia ser um Kafka, um RabbitMQ. Mas qual deles? Aí você falou os dois, aí você vai ter que falar a diferença dos dois. Você entende que cada palavra que você fala é usada contra você. Contra você no tribunal. Ah, eu usaria um Kafka ou um RabbitMQ? Daí o cara falou assim, você usaria um ou outro? Por que você usaria um ou outro? Quando você usava Kafka e quando RabbitMQ? Então se você já tinha dúvida no Kafka, agora você vai ter que saber o RabbitMQ e o Kafka. Entendeu? É... Na verdade eles querem saber o conceito é o conceito então, eles querem saber o conceito mas, aí que é o negócio qualquer entrevista de System Design em algum momento, o objetivo do cara é falar você falar não sei todo mundo em algum momento na entrevista vai falar não sei eu vou falar não sei, você vai falar não sei, porque ninguém é o pica da galáxia de tudo, de tudo, de tudo. Então o que vai acontecer? Eu cheguei lá e falei, olha, isso aqui poderia ser usado o Kafka. O cara falou, ah, legal o Kafka, como que o Kafka funciona? Ah, cara, o Kafka é um sistema distribuído, trabalha com vários clusters, esses clusters se comunicam, trabalham com partições. O cara fala, ok, ele já sabe pelo menos como o Kafka funciona. Mas o cara fala assim, cara, partições, o que é uma partição? A partição é uma forma de ele armazenar os arquivos e conseguir garantir replicabilidade entre os nodes. Bacana, mas se os dados ficam em partições diferentes, como que eu consigo garantir a ordem que as mensagens são lidas? Porque se cada mensagem vai para uma partição diferente, como que eu sei a ordem de chegada? Tem que criar os grupos. Não, não é grupo. Grupo é para consumo. Fala assim, cara, para garantir, eu preciso usar uma aqui. Se todo mundo for com a mesma key, vai cair sempre na mesma partição. Daí o cara vai virar e falar assim, poxa, legal, mas se tiver um assunto que todo mundo tá usando a mesma key, aquela partição vai ficar inteira entorpetada de gente. Então a gente vai ter uma hot partition. Como que a gente consegue evitar que essa partição, ela não fique sobrecarregada e os outros modes acabem ficando colocando só para aquilo. Aí você... Hã? Robin, Robin? Ou não? Está falando da mesma partição? A partição vai ficar sobrecarregada. Daí você tem que pensar, opa, existem estratégias. Por exemplo, se eu estou num sistema financeiro no Nubank e eu tenho clientes que vêm de São Paulo, clientes de Rio de Janeiro para fazer PIX, eu posso criar um tópico de São Paulo, um tópico de Rio de Janeiro, e eu já consigo reduzir o tráfego aí, diminuindo a quantidade disso nas partições. Mas mesmo assim vai ser quente, e entrou mais caras no cluster. Então eu posso criar uma política de rebalanceamento. Então, você consegue perceber que, tá, mas nesse par de rebalanceamento, como que você garante que não vai ter indisponibilidade, porque ele vai ter que ficar movendo as coisas. Daí o cara vai. Até que ele vai chegando numa vaga, até eu falar assim, cara, eu posso ligar pro Ricardo, meu amigo, trabalhando com fluentes, eu acho que ele vai poder me ajudar, porque você vai chegar uma hora que você não sabe, entendeu? Ainda mais se o cara for especialista naquilo. Tá bom? Vai ter... O risco de você nem chegar no final do negócio. É tipo, de tanta pergunta que o pessoal te faz. O ponto é, o quanto mais longe você vai, mais ele vai falando. Esse cara é sênior. Ah, não. Esse cara é tech lead. Não, esse cara é software expert. Esse cara é especialista. Quanto mais longe você vai, mais ele consegue perceber. Porque ele sabe que você vai falar em algum momento, não sei. E o pior de tudo não é falar o não sei. O pior de tudo é enrolar. Pior do que falar não sei é ficar porque é o o que? Eu acho que se fazendo... Meu amigo, o cara sabe, meu amigo. É melhor falar não sei e acabou. Não sei. Eu sei, falei cáfica porque eu já ouvi falar que o cáfica é muito bom nisso, mas eu nunca trabalhei com ele. É melhor acabar aí do que se passar vergonha do cara começar a perguntar de Kafka e você ficar perdendo, entendeu? É melhor falar assim do que... Se rolar aí. O Elton tá tentando falar, então tem um pão aí. Ô, fala, meu amigo, desculpa. O único que tá com a mão levantada é o que não está falando. Desculpa que estou de lado aqui, por causa do monitor. De boa. Acho que talvez esse assunto seria mais para amanhã, mais de comunicação e escalabilidade. Você já ouviu falar sobre o Virtual Actor Model? Não. Não? Actor Model? O Microsoft Orleans, por exemplo, ele é um modelo de Virtual Actor Model, né? E o ACA, ACA do Java, que também, ele não é Virtual Actor Model, mas ele é Actor Model. Onde o próprio sistema, ele se escala, ele cria um nós, você vai criar handlers e esses handlers, você vai esse handler, você pode hospedar ele em vários servidores. Em vários servidores. E tem o supervisor. Supervisor é um supervisor que vai monitorando, vamos dizer, esses nós que ele vai criando, vamos dizer, esses nós que ele vai criando, né? Com isso, se um nó cai, ele pode jogar para outro nó, automaticamente subir e fazer isso aí. E o próprio nó, o próprio render, o próprio nó, esse actor modem, desculpa, ele mesmo já tem uma fila, ele já tem como se fosse um mailbox pattern, não sei se é assim, né? Outbox. Isso, outbox pattern, foi mailbox, né? Acho que não. É outbox. Mas o Google, provavelmente, não poderia fazer algo parecido? Assim, é porque assim, eu vejo assim, eu estava estudando umas coisinhas assim, que a gente tem que criar não infraisinhas assim que a gente tem que criar não infraestrutura, a gente tem que criar software, aplicações que elas se auto escalam vamos dizer o Microsoft Orders é bem interessante porque ele já tem toda eu estou na página dele nesse momento que ele está falando sim, eu percebi que você foi pesquisar nesse momento que ele está falando toda a metrificação eu percebi que você foi pesquisar toda a metrificação ele já monitora, tem até um dashboard que ele monitora todas essas coisas aí cara, o que eu estou gostando nunca utilizei, sempre estudei sobre isso não tem que se fazer load balance para escalar, sei lá ou você talvez evitaria talvez uma mensageria que já estaria nele. Eu não sei até que ponto, né? Cara, não tive. Acho que até esse vibe ver, não sei se ele também começou alguma coisa. O que eu percebo, cara, eu vi um post no LinkedIn esses dias, velho. E esse post ele mexeu muito comigo, cara, muito mesmo. Era um post que falava muito sobre IA, mas na real ele é um post que ele fala de tudo na área de tecnologia. O que que acontece? Toda vez que a gente pensa numa evolução tecnológica, não é que surgiu uma nova tecnologia. Sim. É que alguma foi removida. Como assim removida? Cada vez a gente precisa menos interface para conseguir entregar aquilo que você precisa. Então, antigamente eu precisava de uma máquina que fazia isso. Agora eu não preciso de uma máquina. Agora eu tenho um celular. Agora com o IA eu não preciso mais ter essa interface. Daqui a pouco eu não preciso mais só com óculos. Daqui a pouco é só com pensamento. Quando a gente está falando de evolução tecnológica, o que está acontecendo é que o nível de abstração está ficando tão alto, tão alto, que as coisas que normalmente a gente costumava olhar, elas estão sendo removidas e a gente não vai mais olhar para elas e para olhar cada vez a mais alto nível. É basicamente isso que está acontecendo. É só você pensar que antes você precisava do PC para programar ou para mandar um e-mail. Depois você tem um celular. Agora eu não preciso mais celular. Antes eu precisava mandar um e-mail. Agora eu falo, vai para o e-mail e vai não sei o que. Agora com o chat GPT eu não preciso nem mais ter interface. Eu falo, vai para o e-mail e vai não sei o quê. Agora com o chat GPT eu não preciso nem mais ter interface. Eu falo alguma coisa e o negócio faz. Então, o que eu percebo é que tudo, tudo, tudo está indo para uma linha que cada vez mais a gente vai ter cada vez menos contato com contato mais fino com essas ferramentas. Eu vou dar um exemplo. Vocês manjam do lance de New SQL, né? New SQL, já ouviram falar da história do New SQL? O New SQL, basicamente, é o SQL hoje que em escala infinito. Antes a gente precisava ficar preocupando com escala de máquina, daí ficar pensando em replicação, depois a gente precisava ficar replicando nisso e aquilo, e agora acabou essa história. Eu simplesmente crio uma máquina, a New SQL, sei lá, a Aurora, e acabou. Eu nunca mais me preocupo com banco de dados na minha vida, porque é caro, é caroo mas eu sei que ele vai replicar eu sei que ele vai escalar horizontalmente mesmo sendo um banco de dados relacional eu sei que quando ele não tiver sendo usado ele vai matar os nodes mesmo se ele tiver zero utilizado ele baixa pra zero CPUs então antigamente você precisava, não estou dizendo que a gente não precisa mais de DBA, pelo amor Deus, mas o que eu estou querendo dizer, o nosso conhecimento específico e um monte de tecnologias, daqui a pouco a gente não vai mais precisar. Hoje a gente está falando de placa. Cara, vai caindo mais cada vez uma abstração maior, entendeu? Esse que o... Esse Orleans aqui que ele acabou de passar, é mais uma camada, a Microsoft está cheia dessas principalmente a Microsoft a Microsoft tem lançado um monte de coisa nessa pegada, e com a parada de A, a coisa vai ser mais rápida ainda do que a gente está imaginando esse actor model assim, a tecnologia nova não é, esse cara foi criado é um conceito antigo, acabei de ver é um dos veião lá da Microsoft é nova, não é. Esse cara foi criado... É um conceito antigo, acabei de ver, cara. É um dos veião lá da Microsoft de 1900 e... Pô, dá uma sim, cara. Pessoal, vou me despedir aqui que eu tenho que ir para o almoço, eu tenho que jantar, tá bom? Vai nessa. Galera, eu tenho que ir também porque eu preciso correr 14 quilômetros. Isso. É bem, não é de hoje isso daí Então, inclusive esse esquema Desse Aftermodel foi utilizado No jogo lá, no Halo Da Microsoft A escala Escalável A escalabilidade dele foi feita por esse cara aí De velocidade, de performance Cara, as coisas estão mudando muito rápido E o ponto é que As coisas mudam rápido Os fundamentos ficam. A diferença de um desenvolvedor que consegue trabalhar numa empresa grande e fazer com que esses sistemas escalem, é porque o cara entende o fundamento e ele consegue usar essas ferramentas. Se você pega uma pessoa que não tem fundamento e coloca essa parada pra funcionar, ele simplesmente tá na mão do que acontece com aquela ferramenta e não tem ideia de qualquer tipo de consequência que aquilo pode acontecer, entendeu? Você pega uma criança que não sabe uma criança que não tem noção que ela não pode pular, você bota ela num prédio e fala, voa, ela vai pular, cara é mais ou menos isso a diferença é não, a diferença Você bota ela num prédio e fala, voa! Ela vai pular, cara. É mais ou menos isso. A diferença é... Desculpa, por favor. A diferença é que o não saber fundamento é o que mais faz com que os desenvolvedores acabem se enrolando na carreira. E normalmente, sabe quando esses fundamentos batem? Quando você tá no sênior pra cima porque é ali que o fundamento tá quebrado porque antes disso você é fazedor de crude aí qualquer um faz quando você tá de sênior pra cima, meu amigo o crude, nem é você mais que faz o crude você é responsável pra fazer o negócio rodar por 10 anos, e aí? Essas decisões que tem que ter maturidade pra fazer, se você não entender, se você não estudar, se você não entender de fundamento, se você não entender de arquitetura, se você não entender de um monte de coisa, cara, você não vai entregar. A verdade é essa. Exatamente. É, a internet, essas coisas, te dá uma resposta imediata, mas é rasa, entendeu? Então, a profundada aí não é sólida. E Wesley, podia eu fazer uma pergunta, rapidinho? Manda ver. Manda ver. A última de hoje, galera, porque eu juro mesmo que eu vou correr 14 quilômetros, senão eu não tenho minha meia maratona, cara. Beleza. Não sei se você vai falar alguma coisa a respeito de banco de dados, de armazenamento, mas num sistema de IoT, por exemplo, vai receber milhares de status, de equipamentos e tudo mais, o que você orienta para usar com o banco de dados, com o armazenamento para esse tipo de sistema? Cara, depende se esse armazenamento só serve para mudar status ou você precisa do dado histórico? O dado histórico, pelo menos, por um determinado tempo. Então... Talvez seis meses, sei lá. Então, nesse caso, eu faria duas coisas diferentes. Eu trabalharia com dois bancos de dados, um só para o histórico e um só para os dados específicos que você precisa naquele momento. Entendeu? E os dados históricos, com o tempo, você extrai, bota num Glacier e quando você precisar acessar, que vai ser casos mais raros, você resgata e demora mais para pegar. Mas para você manter dado consistente, você mantém um banco quente e daí os dados ali você vai transferindo e jogando esses dados pra um banco mais frio, entendeu? Eu usaria o MongoDB ou o relacional mesmo? Depende do formato de dados, cara. Depende muito do formato de dados. MongoDB é uma boa pedida sempre, de forma geral, viu, cara? MongoDB resolve muito problema, inclusive problemas de banco de dados relacionais, cara, eu gosto muito do MongoDB, cara, é uma puta ferramenta. E ele calcula geolocalização nesse caso aí. É, ele tem, ele trabalha com, ele trabalha também com com algoritmos pra geolocalização, ele trabalha com bastante coisa, o que eu vejo muito gente fazer pra IoT, quando é pesado, usar o Kafka mas depende muito da coisa porque o Kafka pra isso é muito bom por um motivo o Kafka, ele recebe uma grande quantidade de dados do stream mas ele tem ferramentas em volta dele como o Kafka Connect o que que acontece? O dado cai no Kafka o seu sistema lê, atualiza o seu banco quente, e o Kafka Connect vai jogando esses dados pra um outro banco de dados sem você ter que programar nenhuma linha. Entendeu? Então o Kafka Connect, ele ajuda você a fazer integração com outros sistemas. Então, a grande vantagem do Kafka, cara, não tá só no Kafka, tá no ecossistema. O Kafka tem o KC Code B, Kafka Streams, ele tem o Kafka REST, que a gente vai falar amanhã pro lance do Uber, tá? O Kafka, ele tem o REST Proxy, ele tem o KC Code B, ele tem, cara, ele tem uma porrada, o Schema Registry, ele tem um monte de coisa que não é só o Kafka, entendeu? eu acho que o grande poder do Kafka não está só no Kafka está no que está em volta dele entendeu? e é aí que está a diferença top, valeu pela dica vamos dormir até amanhã, espero que vocês estejam aí espero que vocês tenham curtido aprendendo algo e a gente vai se falando, galera um abraço aí pra vocês, boa noite boa noite