Galera, o negócio é o seguinte, hoje a dinâmica vai ser um pouco diferente, tá? A gente não vai quebrar em sala, vocês não vão necessariamente fazer o System Design e esse tipo de coisa, mas a gente vai pegar o System Design baseado no case do Uber ontem. Eu não sei se vocês lembram como que eu terminei, mas basicamente a ideia principal ali foi fazer com que todos aqueles endpoints que foram documentados apontassem para o System Design e a gente não pensou nada em formato de comunicação. E a gente não pensou em resiliência, a gente não falou de banco de dados, a gente não pensou nada em formato de comunicação. E a gente não pensou em resiliência, a gente não falou de banco de dados, a gente não falou de absolutamente nada disso. Então, por isso que eu tentei deixar sempre o mais claro ontem de que aquela versão que a gente estava criando era somente para implementar aqueles métodos e eu até brinquei. Não vou copiar e colocar isso no LinkedIn, do jeito que está, senão vão falar que eu estou ficando maluco de ensinar um negócio daquele jeito. Então, hoje é o dia que a gente vai pensar exatamente em como que nós vamos melhorar aquilo que a gente criou. Agora, o grande ponto é que nós, quando a gente vai criar uma arquitetura, quando a gente vai desenhar uma solução ou qualquer coisa desse tipo, o que acontece? Ou a gente simplifica muito, ou a gente adiciona muita coisa. Então, hoje é o dia que a gente vai tentar balancear um pouco tudo isso. Por que eu estou dizendo isso? Porque existem contextos e contextos. Se você tem um projeto na sua empresa e você tem que criar pelo menos o system design daquilo, dependendo para quem você vai mostrar, aquele desenho vai ter um nível mais alto. Dependendo pra quem você vai mostrar, aquele desenho vai ter um nível mais alto. Dependendo pra quem você vai mostrar, aquele desenho vai ter um nível um pouco mais baixo. Dependendo pra quem você vai mostrar, o baixo nível vai ser um pedacinho do System Design, com muito mais detalhes pra conseguir fazer ali um zoom em relação a algumas especificidades dali. Então, o que eu estou querendo trazer aqui hoje para vocês é a gente entender as possibilidades que a gente tem de comunicação no sistema, e como que a gente pode explorar essas possibilidades com prós, contras, e como que a gente vai aplicar essas possibilidades, com prós contras, e como que a gente vai aplicar esse tipo de coisa no system design que a gente está trabalhando o system design que a gente está pensando de forma geral do Uber e por que eu não fiquei focando tanto nos requisitos de nos planos de capacidade, porque todo mundo aqui já está... Porque independente do plano de capacidade que a gente monte, especificamente no caso do Uber, qualquer número que a gente colocar aqui, ele já vai ser surrealista. A gente está falando ali de muitas transações por segundo. Chega um ponto de ter transações por segundo que um banco de dados como o Postgres, ele não consegue acompanhar. Se a gente está falando em geolocalização, o negócio é para outro nível ainda, e aí tem diversas soluções especificamente para o caso da parte de geolocalização. Tinha até um camarada ontem aqui que trabalhava na Localiza, e ele falou de uma das soluções que eles acabam trabalhando lá, na parte de geohash, e a gente vai cobrir um pouco isso aqui também. Então, a nossa ideia hoje, a estrutura do nosso bate-papo hoje vai ser o seguinte, a gente vai falar um pouco sobre formatos de comunicação, a gente vai voltar naquele system design que a gente mexeu ontem, depois nós vamos refazer esse system design, a gente vai discutir alguns pontos em cima dele, depois a gente vai refazer esse cara de novo. Agora, obviamente pessoal, eu quero otimizar o nosso tempo. A sessão de ontem, ela foi bem puxada, foi muito tempo. Para mim, na real, é um prazer, mas eu sei que todo mundo trabalha no dia seguinte e tudo mais, então eu não quero que essa sessão seja tão longa. Por outro lado, eu não quero também aqui que vocês entrem com uma sensação que vocês fizeram, assistiram uma simples live no YouTube e não puderam interagir, não puderam perguntar e a gente não poder trazer reflexão. Eu acho que a grande sacada não é fazer um monte de desenho. É conseguir, uma vez que você tem os desenhos, começar a colocar alguns dedos nas feridas. E são esses apertãozinhos aí é o que vai acontecer com o seu chefe, que vai fazer perguntas para você ou com o seu tech lead. Ou se você é tech lead, você tem que pensar, será que eu estou fazendo esses tipos de perguntas para os meus liderados que estão propondo soluções? Ou também, vão ser os tipos de perguntas que quando você estiver numa lousa branca, para entrar numa big tech, os caras, eles vão começar a apertar, tá? E apertam mesmo, tá? E apertam gostoso até você falar não. Então, o grande ponto é, a gente vai tentar ir um pouquinho mais a fundo em alguns problemas, em algumas questões que eu tenho absoluta certeza que ou vão cair numa entrevista, ou se você estiver trabalhando com um sistema de grande escala, esses problemas vão acontecer. Agora, o grande ponto é, se você já sabe hoje em dia que esse problema vai acontecer, você já consegue pensar na arquitetura, como que ela vai ser feita de antemão, e principalmente, sem fazer aquele overengineer todo, que às vezes acaba mais complicando o projeto do que deveria, tá? Mas o fato é que a pior coisa que pode acontecer para qualquer desenvolvedor é não saber do que ele não sabe. Essa é a grande questão. Saca? E esse tipo de questão é tão complicada porque... Eu vou tentar, já que a gente estava falando de A agora há pouco, quem é que hoje em dia usa o chat GPT ou qualquer outra pra fazer pergunta de código, ou pedir pra ele escrever um teste, ou tirar uma dúvida quando aparece ali o tempo inteiro? Virou o melhor amigo ali, né? Na realidade, né? O tempo inteiro ali, cara, eu uso essa parada o tempo inteiro. Mas, se você fizer uma reflexão, você só consegue perguntar daquilo que você entre aspas sabe que existe. Como assim? Vamos imaginar que a gente acabou de falar nesse termo geohash. Se você nunca ouviu esse termo e de repente você tem que resolver um problema que vai precisar do geohash, ou seja, você não sabe que isso existe com certeza a sua pergunta do GPT não vai te ajantar, por quê? porque você nem sabe daquilo que você não sabe entendeu? você vai ter que começar a fazer uma exploração do tipo, quais são todas as formas de algoritmos para eu fazer geolocalização, ele vai mostrar um monte, como esse funciona qual que é o outro, e daí quando você vai ver você vai ter que ficar na realidade dando um super tiro no escuro pra ver o que que ele traz pra ver o que é de relevante pra você começar a estudar aquilo então o maior problema que a gente tem, usando o IA ou não usando o IA, tá? E eu vou até mais longe. A IA é algo, assim, maravilhoso. Eu uso diariamente. Não tem como não usar. O maior problema que a IA nos traz, principalmente pra gente na área de tecnologia, mas eu acho que em outras áreas também, ela nos dá uma falsa sensação de autossuficiência. Tá? Uma hora que você tem a IA do seu lado, não tem dúvida que não possa ser respondida. É mais ou menos essa sensação, né? É só ver quanto tempo vocês pararam de ficar acessando o Stack Overflow nos últimos tempos, depois do 7GPT. Eu vivia no Stack Overflow. Agora, a grande questão é que uma coisa é, de fato, você consegue aprender muito, conseguir trazer muita informação. Mas o grande ponto é que às vezes a gente acaba tendo a falsa sensação de que a gente tem tudo que a gente precisa na nossa mão. E por que eu digo que é falsa? Porque você não sabe o que você não sabe. Então, se você não sabe que aquela parada existe, você nunca vai perguntar ela. E quando você começa a entrar nesse tipo de situação, você vai ficar sempre limitado ao repertório das palavras, das tecnologias que você conhece. Qualquer coisa que fure a bolha daquilo que você não conhece, você não vai saber nem o que perguntar, porque você não sabe que existe. Eu vou dar um exemplo para vocês. Quem falou para mim ontem do Orleans, da Microsoft? Alguém estava aqui ontem? Algu alguém fez uma pergunta, alguém fez alguma falou alguma coisa sobre isso ontem e a minha primeira resposta que eu dei na hora pra pessoa foi não sei, eu nem enrolo galera se eu não sei uma parada, eu falo não sei na cara e tenho zero recalque de não saber as coisas, entendeu? como eu não sabia que aquela parada existia eu jamais procuraria sobre aquilo. Entende qual que é o grande ponto? Então, o que a gente tem que tomar cuidado como desenvolvedor nos dias de hoje é não ter a falsa sensação de que a gente tem tudo na nossa mão, que a gente não tem. E normalmente... Ah, desculpa. E normalmente, os problemas que acabam sendo específicos de um negócio, principalmente problemas altamente complexos, raramente vai ser ou uma resposta, ou uma live minha que vai resolver todos os seus problemas, ou um livro que você vai ler. Então por isso que ter uma visão meio que geral das coisas, ela vai falar, opa, eu não sou especialista em WebSockets, mas eu sei que se eu precisar de comunicação bidirecional, client-server, mantendo uma conexão estabelecida, WebSocket é uma opção que eu vou ter para alguma coisa. Aí eu vou pesquisar mais a fundo e tento resolver. Mas é importante que eu saiba que essas paradas existem. O grande problema dos desenvolvedores é que, quando eles acham que aquilo não faz sentido para eles naquele momento, a pessoa acaba não estudando. E eu vou provocar vocês trazendo exatamente alguns pontos da aula que eu coloquei do segundo capítulo lá na plataforma. Quem aí teve e chegou a acessar e assistir a aula de comunicação que eu coloquei? Que é um apanhado. Aí tem uma galerinha aí, ó, muito bom, saber que não foi um, como se diz, um investimento que ninguém assistiu o negócio, né? Gravou e ninguém viu. Não, beleza, galera. Show de bola. Fico feliz em saber que vocês assistiram. A gente vai usar aquilo como base, mas o meu principal ponto ali é a gente conseguir trazer as discussões de quando, como, em qual momento aquilo deve ser utilizado e, inclusive, trazer discussão aquilo deve ser utilizado e inclusive trazer em discussão se alguém utiliza aquela parada. É muito louco esse tipo de coisa porque às vezes a gente faz alguns posts no LinkedIn, no Instagram ou até vídeos no YouTube e o nível de... e pelo amor de Deus não entenda que eu tô falando isso de forma pejorativa, tá? O nível de ignorância, não ignorância porque o cara é burro, ou que um cara é mau, ou qualquer coisa desse tipo, mas o nível de falta de conhecimento, especificamente naquele ponto, faz com que as pessoas, elas acabem falando umas besteiras bem grandes, entendeu? E é esse tipo de coisa que eu quero evitar, eu evito fazer porque às vezes eu também falo besteira, também sou ignorante, né? Você não é, eu sou, mas a grande questão aí é que, eu vou dar um exemplo para vocês. Um tempo atrás, a gente fez um post sobre protocol buffers. Tá? Falando o quanto protocol buffers ele consegue ser extremamente mais performático do que trabalhar com serialização utilizando o JSON. E coloquei. Aí, teve um comentário que a galera colocou lá no LinkedIn falando o seguinte, um monte de gente marcando quem conhece o Eric aqui? o Eric Wendel? bom, ok não tem problema, o Eric é um cara super bacana, eu conheço ele, sou amigo dele e tudo mais, e ele manja bastante JavaScript, um tempo atrás ele fez um vídeo no YouTube mostrando como com streams ele conseguiu fazer o insert de um milhão de registros e etc, e blá blá blá e daí eu coloquei foi o nosso post sobre gRPC a gente falou sobre protocol buffers que era muito mais rápido que JSON e daí algumas pessoas colocam, você não sabe o que você está falando fala com o Eric, que ele vai te mostrar como que ele pegou esse monte de ações e enfiou em não sei quantos segundos, não sei quantos milhões de registros no banco de dados. Então, o que eu estou querendo dizer com isso? Simplesmente, a pessoa não conseguiu nem entender qual era o problema que estava sendo colocado. A questão não é se alguém consegue colocar mais registro ou não no banco de dados. A questão é muito clara. Uma coisa é você ter um documento em texto. Outra coisa é você ter um arquivo binário que tem o tamanho muito menor. Uma coisa é você serializar um arquivo JSON gigante e usar um monte de CPU. Outra coisa é você serializar um arquivo JSON gigante e usar um monte de CPU, outra coisa é você deserializar um arquivo binário. Outra coisa é você usar flat buffers, a gente vai falar sobre isso, onde não há serialização e o arquivo ainda é binário. Então a questão não é se o cara enfiou um trilhão de registros no banco de dados. A questão é simplesmente que é um fato, entendeu? E o grande ponto é que qualquer coisa que está fora daquilo que a gente está acostumado, e nesse caso, o que a gente está acostumado? API HTTP mandando JSON. A real é essa, né? É o que todo mundo está acostumado, eu estou acostumado, é o que a gente nasceu, cresceu, e etc. está fazendo. O ponto é que, quando você for pegar grandes problemas em grandes empresas, simplesmente, isso não vai fazer você passar nem na porta da entrevista, se você falar alguma coisa desse tipo. Entendeu? E às vezes o entrevistado ainda sai falando mal da empresa. E, na real, às vezes o entrevistado sai falando mal e não sabe nem por que foi reprovado porque ele nem se tocou o que ele acabou de falar entendeu? e quando o entrevistador dá o feedback a pessoa ainda não concorda porque fala que o JSON é o mais utilizado no mundo e é por isso que tem que ser utilizado a questão não está no JSON, não está no GRPC o grande ponto que eu quero trazer aqui pra vocês é que a gente não pode ficar tapado numa bolha achando que de só JSON e REST vive o homem, mas, né, a gente tem muita opção e não é porque existe que a gente tem que usar também, tá? A gente tem que conseguir moderar muito isso, tá? Então, deixa eu compartilhar minha tela aqui pra gente começar, mas essa é um pouco da introdução que eu queria trazer pra eu não simplesmente sair jogando um monte de letrinhas aqui pra vocês e vocês também entenderem. O que eu tô querendo trazer aqui é contextualizar a importância de a gente saber, pelo menos que existe, e pelo menos ter uma ideia pra que, quando aparecer um problema na sua frente, opa, talvez aquilo que eu ouvi naquele bate-papo com o Wesley em janeiro, né, talvez faça sentido agora. Entendeu? Então, essa eu acho que é a grande pegada. Beleza? Então, deixa eu compartilhar a a grande pegada. Beleza? Então, deixa eu compartilhar a parada aqui, só um segundinho. Então, show de bola. Acho que está todo mundo vendo aqui a minha tela agora, né? Show? Maravilha! Pessoal, seguinte, eu vou revisar rapidamente aquilo que eu passei na aula que está na nossa plataforma, beleza? E eu quero trazer algumas discussões sobre esses tipos de forma de comunicação, e a gente vai fazer uma relação disso com o System Design de ontem, e baseado nisso eu vou trazer algumas versões do System Design que a gente vai colocar até a gente chegar, entre aspas, numa versão final que pode ser adequada, sei lá, por exemplo, seria super ok, talvez, numa entrevista. O Leonan, bloqueia pra que as pessoas não fiquem rabiscando na minha tela, por favor, alguém acabou de rabiscar na minha tela. Eu não sei porque que acontece isso no Zoom, mas esse risco azul aqui, galera, não fui eu que fiz, tá? Então, beleza aqui. Deixa eu colocar aqui pra gente. Pessoal, novamente aqui, tá? Existem, né? Eu não quero ficar falando coisas tão, entre aspas, de forma geral, base, básicas aqui, mas somente para a gente recapitular. Requisições síncronas. Eu mando e a pessoa recebe a resposta na hora. Ou seja, é falar no telefone. Eu falo, você responde e acabou. Não tem nenhum momento onde eu tenho que ficar aguardando, tá? O aguardo é o tempo de processamento, ok? Esse tipo de requisição, em muitos momentos, né? E na maioria dos momentos, elas são extremamente importantes, que é o que acontece no dia a dia que a gente está fazendo, são as nossas APIs e etc. Aqui, tá? Eu coloquei aqui como REST, mas pode ser qualquer coisa que a gente consiga fazer comunicação ali, tá? Então, a grande sacada é que as duas pontas precisam estar online para esse tipo de comunicação acontecer. Ponto. Simples assim. Não vou ficar muito... Acredito que todo mundo aqui já conhece, inclusive, esses conceitos, mas eu só quero manter todo mundo na mesma linha de raciocínio. Requisição assíncrona. As pontas, elas não precisam estar conectadas ao mesmo tempo para trocar informação. Eu mandei um e-mail, quando o cara receber aquele e-mail, ele responde ou ele deleta o e-mail. O ponto ali é que as pessoas não têm que estar ligadas naquele momento. Mas uma coisa é importante, que quando a gente está falando de mensagens ou comunicação assíncrona, de uma forma ou de outra, precisa haver um meio onde essas comunicações aconteçam. Precisa ter um meio onde alguém mande aquela mensagem e existe algum meio onde aquela pessoa vai ter que recuperar aquela mensagem. O fato ali naquele momento é que as pontas não estão ligadas, mas essas pontas, elas têm que ter um local aonde elas acessam essas informações que elas foram enviadas. Certo? Protocolos aqui muito comuns, que eu não quero nem ficar passando muito tempo, mas eu quero falar uma coisa importante aqui pra gente, tá? Quando a gente tá falando de HTTP hoje em dia, né, e que normalmente as requisições que a gente faz é via REST utilizando, né, independente do nível de maturidade do REST, a gente tem que se ligar o seguinte também, pessoal. O protocolo HTTP, ele mudou bastante, né, na versão 2. Quem hoje em dia trabalha diretamente com HTTP 2? Realmente, utilizando recursos do HTTP2. Isso aí, se você não está fazendo isso, eu acho que a grande sacada que eu posso te dizer é por que não? E quais são alguns impedimentos que fazem com que normalmente você acabe não utilizando o HTTP2? Existem algumas pegadinhas e essas pegadinhas são importantes para vocês anotarem. Às vezes até o seu servidor web, vou dar um exemplo, o programa com Go. O Go tem suporte a HTTP2, tá? Agora, por que na maioria das vezes que eu tô utilizando o Go, eu não tô trabalhando com HTTP2? Cara, pode ter N motivos. Eu vou dar um exemplo muito claro pra vocês. Quem é que usa Cloudflare? Deixa eu olhar as mãos nos participantes aqui tô olhando no chat aqui, fica melhor galera toda usa Cloudflare o que que acontece? Cloudflare é um cara que é a vida hoje em dia é muito comum todo mundo grande parte das pessoas que eu conheço trabalham pra caramba com a Cloudflare. A Cloudflare, no final das contas, ela vira um intermediário, ela vira um proxy, ela vira um roteador recebendo essas informações e reencaminhando a informação para os nossos servidores. É muito comum uma requisição acontecer via HTTP2 através da Cloudflare, mas na hora da Cloudflare reencaminhar os dados para vocês, ela vai mandar via HTTP 1.1. E aí você pensa que está usando HTTP2, mas na realidade você não está. Outras coisas que acabam acontecendo também é muitos servidores web que a gente acaba trabalhando, eu vou dar um exemplo novamente do Go, porque é o que eu tenho mais familiaridade nos dias de hoje. O Go, por padrão, ele também, não necessariamente por padrão, mas com uma configuração muito boba, o HTTP2 ali fica rodando tranquilo com tudo quanto é recurso, etc, que a gente acaba trabalhando. O grande ponto é que, por padrão, o HTTP2 parte do princípio que você precisa utilizar TLS. Então, o que acontece? Você tem um servidor web, no caso do Go, e você não está com a configuração do TLS ativa naquele servidor web, você vai rodar usando o HTTP 1.1. Então, por que que na maioria das vezes, quando a gente está trabalhando com o web server, a gente ainda está usando o HTTP 1? Porque na maioria das vezes, a gente tem um proxy na nossa frente que recebe as informações via TLS, com HTTPS e toda aquela história, e aquilo reencaminha as mensagens pra gente e quando a gente recebe esse encaminhamento esse encaminhamento ele não é feito via HTTP2 e aí a gente fica com aquela falsa sensação da utilização do protocolo então, novamente galera, sabe esse tipo de coisa? Pode parecer uma boa besteira, mas só de você utilizar HTTP 2, muda completamente o nível de velocidade das suas aplicações. Eu vi no chat, passando, galera, eu não estou nem conseguindo olhar de perto, tá? O chat, porque acaba passando um monte de mensagem. Mas o lance aí é, teve gente que falou, talvez HTTP 2 não funciona nos browsers. Na realidade, é onde a gente consegue tirar mais proveito, porque você consegue numa requisição mandar um monte de coisa, tá? Então, mesmo a gente falando de HTTP, tá? Tá, mesmo a gente falando de HTTP, tá? Tá aí mais uma coisa pra vocês anotarem hoje, pra vocês analisarem amanhã. Primeira coisa, vocês estão trabalhando com HTTP 2? 2. Quais são as principais vantagens principais que o HTTP 2 traz pra você? 3. Você precisa disso? Tá? Será que é só um HTTP2 igual a true no seu código e você poderia multiplicar a velocidade do seu... do tempo de resposta do seu software em 50%? Já pensou? Saca? Então, depende muito da forma que você vai precisar. Existem um monte de servidor web, existe um monte de proxies, existem diversos cloud providers, diversos caminhos, abstrações, API gateways, proxy reversos, Nginx e coisas desse tipo. Se esses caras não estiverem bem configurados, você não vai ter acesso a recursos que vão aumentar muito a capacidade da sua aplicação. Então, até em detalhes muito bobos, que é o HTTP, que em tese todo mundo sabe e etc., eu vejo pouca gente falando do HTTP2, mas que está aí faz muito tempo na realidade, tá? Então esse aí é um ponto importante aí pra vocês. Beleza? Somente pra colocar. Então quem aqui não está trabalhando com HTTP2 ou não sabia disso que eu acabei de falar, coloca uma mãozinha pra baixo, só pra eu ver no nível de participante, tá? Só pra ter uma noção. Deixa eu clicar em participantes aqui pra aparecer aqui pra gente. Porque o Zoom é muito maluco, velho. Cara, ele abre uma janela muito louca aqui, ó. Ah, tem várias mãozinhas aqui pra baixo. Galera, não se sintam mal. Eu também tenho um monte de aplicação minha que a gente não rola com o HTTP2. Eu nem sei porquê, tá? Bom, eu vou revisitar a minha própria listinha que eu tô falando aqui pra vocês hoje, tá? Mas, vale a pena revisitar, galera. São coisas básicas e aquele arroz com feijão bem feito é o que vai fazer diferença na maioria das vezes na sua empresa. Não vai ser aquela tecnologia fancy que todo mundo quer colocar. Às vezes, simplesmente, você muda um parâmetro de configuração no web server, você muda completamente a velocidade com que os clientes conseguem trabalhar. Legal? Agora, a gente tem um outro cara conhecido aqui, que é o GraphQL quem já trabalhou com ele agora, levanta a mão coloca, não é levantar a mão, dá o joinha o levantar a mão é pedir pra falar tá galera, só pra vocês saberem o levantar a mão é pra saber, é pedir pra falar tá muita gente só testou, muita gente trabalha e etc galera, eu vou falar uma coisa pra vocês. O GraphQL é um cara que mais me desapontou nos últimos tempos. Tá? Na minha opinião, esse cara surgiu uma proposta fantástica e no final das contas ele acabou não tendo uma adesão tão forte. E hoje em dia, honestamente, eu vejo poucas pessoas falando, usando de forma tão ativa e falando, eu vou trabalhar e já vou fazer questão de disponibilizar esses meus endpoints tudo com GraphQL. Agora, antes de falar especificamente sobre o uso ou desuso de GraphQL, o que eu quero que vocês tenham em mente é que qualquer coisa que roda via HTTP, de uma forma ou de outra, é uma espécie de requisição RPC. Como assim? Eu acho que todo mundo, ou acredito que grande parte de vocês, já ouviu falar do famoso RPC. Eu lembro que quando surgiu toda aquela história de SOA, Service Oriented Architecture, as comunicações entre sistemas e etc., a gente falava muito em RPC, Remote Procedure Recall. Basicamente, você manda uma requisição para rodar um processamento de algo, normalmente era um XML gigante, num outro local. Ou seja, era uma chamada pra um outro cara. E nessa chamada, você passava uma especificação, né? A principal diferença que a gente poderia olhar hoje, de diferença de REST barra HTTP, é que na realidade, o REST, ele tem uma representatividade baseado nos métodos, da forma como ele é organizado, nos níveis de maturidade, que você já implica semanticamente o que você vai querer executar em algum server. Mas se você olhar a grosso modo, tá? O GraphQL, quem aqui nunca, não sabe o que é GraphQL, galera? Por favor, escrevam aí. Quem não sabe, fala. Eu não sei. Tá? Quem não sabe o que é GraphQL. Mas, se você perceber, a primeira vez que eu vi falar em GraphQL, a primeira pergunta que eu me fiz foi qual a diferença entre GraphQL e RPC? Tá? E eu lembro que eu fiz essa pergunta pra uma pessoa que estava assim, acalorada pelo hype do GraphQL. E eu já vou falar pra vocês, quem não manja o que é GraphQL, como é que essa parada funciona. E a pessoa simplesmente me tirou de idiota. Falou assim, cara, você não sabe do que você tá falando, cara. Uma coisa é GraphQL, outra coisa é RPC. Tá? Mas o que que acontece? Se você for falar aqui em RPC, caraca, cara, por que que eu mesmo não tô conseguindo editar meu próprio documento? Se você mesmo for falar em RPC, basicamente, cara, o zoom fica aparecendo um monte de notificação pra mim e aí fica, eu não consigo escrever peraí. Basicamente o que a gente acaba tendo aqui no RPC é uma especificação do que você tem e do que você quer que seja executado num local pra baseado num retorno que você quer. E isso normalmente acontecia via HTTP. A ideia aqui do GraphQL, se você perceber, é uma chamada que vai acontecer, RPC, que você vai pedir para rodar alguma operação e ela vai te retornar algo de acordo com uma especificação extremamente clara. Então, tá? Se você olhar de uma forma muito clara, GraphQL ele tende muito a ser uma derivação obviamente mais sofisticada do que uma chamada RPC, tá? E pra quem não sabe o que é GraphQL, galera, a grande sacada é o seguinte, hoje, quando nós temos, né, uma aplicação qualquer, né, que a gente tem trabalhando, sei lá, com REST, às vezes eu preciso às vezes eu preciso... Às vezes eu preciso simplesmente fazer algumas coisas. Eu preciso pegar uma chamada onde eu vou receber o nome, e-mail, onde eu preciso nome, e-mail e telefone de alguém. Mas na hora que eu faço essa chamada, eu recebo nome, e-mail, telefone, endereço e recebo um monte de coisa aqui para mim. Quando eu tenho nome, e-mail e telefone e depois eu recebo endereço, CEP, cor da cueca, não interessa quais são os dados, o que está acontecendo aqui? Eu estou trafegando mais dados do que eu preciso. Quando eu recebo dado a mais, eu tenho que tratar, eu tenho que filtrar. O usuário recebe mais dados, o meu front-end vai ter que ficar processando um monte de informação. Então, a ideia é ótima. Eu falo quais dados eu quero receber e ele retorna só os dados que eu quero receber. E se eu quero fazer uma mutação, ou seja, uma alteração dessas informações, eu passo somente o que eu quero fazer essa mutação e ela altera. Ou seja, o mais interessante de tudo isso é que o mundo, e principalmente a galera de front-end, falou, cara, era tudo isso que eu queria, porque às vezes a pessoa tem que fazer um monte de chamada, REST, para pegar um monte de informação, combinar essas informações para conseguir, sei lá, popular um front-end. Com GraphQL, com uma única requisição, você recebe todos os dados de uma forma toda encadeada, bonitinha, para que você consiga trabalhar. Então, assim, sabe aquelas coisas que a ideia é maravilhosa e que é muito top, mas no final das contas não pegou? Isso é o GraphQL galera eu não sei porque não pegou, eu acho que talvez um pouco pelo nível de complexidade e também pela cultura que a gente tem de fazer chamada, HTTP com REST, etc mas infelizmente não foi algo que foi pra frente mas não é uma tecnologia que morreu então, se você nunca tinha ouvido falar em GraphQL aqui foi algo que foi para frente, tá? Mas não é uma tecnologia que morreu. Então, se você nunca tinha ouvido falar em GraphQL aqui, eu recomendo que pelo menos você faça um estudo muito rápido desse cara, faça uma implementação simples, somente para você saber se eu preciso escolher os dados que eu quero alterar ou se eu preciso escolher os dados que eu quero receber sem ter informação nem a mais nem a menos, o GraphQL é realmente uma solução útil. E não é porque ninguém está usando, ou você não vê por padrões, API de API no mundo para fora, utilizando o GraphQL, que não significa que isso não tenha um estudo de caso dentro da sua empresa. Normalmente o que eu vejo é que muitos desenvolvedores começam a olhar o sistema deles somente da porta da frente pra rua. Mas quando você tá trabalhando numa empresa muito grande, a porta da frente é apenas a ponta do iceberg. Sei lá, o Merc o mercado livre tem 30 mil microserviços será que ali não existe algum caso que esse tipo de tecnologia poderia ser aplicado ou não? não sei se eles usam, não sei se eles não usam e pra mim não importa nesse momento, a grande questão é que uma vez que você sabe que você tem opções você sabe que você tem opções, você sabe que essa tecnologia existe e que, eventualmente, vale a pena você fazer uma prova de conceito. Agora, apesar do GraphQL ser uma tecnologia que, aparentemente, não despontou tanto, esse cara aqui é o cara que eu quero mais chamar a atenção de vocês hoje, tá? Que é o GRPC. Toda vez que eu falo em GRPC, né? Muita gente torce o nariz e fala é muito mais complexo de se usar, ninguém utiliza, você pode olhar que todas as APIs que você tá vendo hoje em dia é tudo REST, quem aí já viu aí liberado para integração a utilização de gRPC e aqui eu vou fazer uma pergunta rápida e simples para vocês aqui no chat, tá galera o seguinte quem aí já viu endpoints em aplicações de terceiros para você se conectar via gRPC? Eu acredito que, assim, são muito poucas pessoas. É muito raro você ver, tá? Por quê? Existem alguns motivos bem você ver, tá? Por quê? Existem alguns motivos bem claros, tá? Eu acho que o primeiro motivo é que o REST é algo tão simples, tão tranquilo de você integrar, que quando você tem, sei lá, eu vou fazer uma integração de pagamento com o P, sei lá, eu vou fazer uma integração de pagamento com o Pagar.me, eu vou fazer uma integração não sei com quem, com a outra aplicação e etc. Cara, você vai ter um monte de endpoint REST pra você se comunicar. Mas, novamente, a gente tá falando da porta pra fora. Em algum momento, se você pegar uma empresa que é lotada de microserviços e esses sistemas, principalmente, obviamente, de back-end para back-end, tem que se comunicar o tempo inteiro, nesse momento, você tem que levantar uma luz amarela na hora e fazer a pergunta por que esse tipo de comunicação aqui tá rolando via REST e não tá rodando via gRPC tá quando a gente cai nesse tipo de situação onde a gente tá da porta de casa pra dentro e a gente dependendo do tipo de sistema que a gente está da porta de casa para dentro e a gente, dependendo do tipo de sistema que a gente vai trabalhar, a gente está usando o REST para tudo, eu tenho absoluta certeza, isso está feito simplesmente por comunidade e por padronização dentro da empresa. Quando você tem tráfego para caramba e precisa de requisições trabalhar de forma assíncrona, simplesmente é incomparável você trabalhar usando HTTP, com REST, ou você trabalhar com GRPC. Pra quem não sabe e não conhece GRPC, GRPC é uma forma de RPC, ou seja, de você executar remotamente uma operação em um outro servidor. Basicamente é isso. Agora, a grande sacada do GRPC é que... E o G não tem a ver com o Google, apesar de ser nascido no Google, ninguém sabe de onde veio o G, mas o Google fala que o G não é por conta do Google, só por curiosidade, tá? Mas a grande sacada aqui é o seguinte, o GRPC, ele trabalha com HTTP2. Os dados são comprimidos, já por padrão no HTTP2. A gente trabalha aqui com tráfego de protobuf. Basicamente, são arquivos binários que contêm as suas informações serializadas. Então, o que acontece nesse tipo de caso? Você consegue trafegar sua informação para um protocolo mais rápido, esse seu dado já é comprimido, tá? E quando alguém recebe esse dado, a serialização e a deserialização é muito mais rápida que JSON. E daí você fica pensando, se eu tenho algo que é tão superior ao famoso HTTP com REST, o porquê eu não o utilizo e eu queria saber as teorias de vocês aí tá? eu queria saber a teoria da galera, porquê que se você tem claramente uma tecnologia que é infinitamente dependendo do contexto, superior à outra, ela acaba sendo pouco utilizada dentro de empresas, inclusive da porta para dentro. Então, o que eu estou querendo dizer com isso, pessoal? Existem alguns pontos que eu quero levar isso em consideração, principalmente partindo do princípio que eu estou falando com mais desenvolvedores sêniores hoje aqui. Nós temos uma mania gigante de trabalhar no piloto automático. Tá? Meu framework já vem tudo bonitinho com REST. Ah, aquele cara já está acostumado com REST. A minha documentação já está não sei o que com REST. Isso aqui já está não sei com REST. Para que eu vou mudar? Os funcionários que estão aqui já estão com REST. Assim, assim, assado. Eu acho que isso é algo cultural, é algo de padrão, tá? E tá tudo ok, faz parte do jogo. Aquela mesma história. Não é porque você tem o melhor produto no mundo que é o cara que mais vai vender, tá? Mas, o que eu digo nesse tipo de situação é eu acho que realmente, galera, dependendo do tipo de sistema, do nível de criticidade, do nível de concorrência que tem em cima desse sistema, e se você tem uma equipe que não está acostumada a trabalhar com um determinado protocolo, para que eu vou querer complicar algo que todo mundo já sabe e que vai atender e que não vai matar ninguém para eu utilizar? Ok? Pra que que eu preciso disso nesse caso? Nesses casos. Então, isso pra mim é entendível, tá? Isso pra mim faz todo sentido. Eu não vou ficar inventando algo que é padrão pra toda empresa e que todo mundo já sabe e etc e tudo mais. Mas, qual é o grande problema? Quem aqui trabalha ou quer trabalhar em uma grande empresa? E essa grande empresa, ela realmente precisa ter, lidar com muitas transações por segundo. Tá? Se você está nessa situação ou se você quer estar nessa situação com certeza existem serviços que devem estar gritando naquele momento algo do tipo com certeza existe algo melhor do que REST pra ser encaixado aqui. Tá? Então, nesse momento, o que eu quero colocar aqui pra vocês, né? Novamente, pra vocês pensarem. Será que aonde você trabalha, na empresa grande que você trabalha, naquele sistema que direto você tá tendo que escalar um monte de máquina para resolver alguns problemas, será que não valeria a pena você fazer um teste e pegar apenas um endpoint? Você não precisa refazer a P inteira. E fazer um teste e um benchmark, colocando uma tecnologia diferente, nesse caso como um GRPC da vida? Porque uma coisa a gente tem aqui, tá? É fato, é fato técnico, tá? Você trabalhar com GRPC, rodando em cima do HTTP2, trabalhando com protobuf, vai ser mais rápido que REST de qualquer forma. Acabou, é indiscutível isso. Ah, mas tem um caso que o cara fez mais rápido, é porque o cara que fez GR RPC fez mal. Entendeu? Provavelmente é isso. Porque bater as especificações, a tecnologia por tecnologia aqui nesses casos, acaba sendo bem incomparável esses tipos de coisa. Para vocês terem uma ideia, e obviamente nem todo mundo vai trabalhar na Google, ou aqui eu trabalho na Google, mas para vocês terem uma ideia a grande parte é que eu não quero chutar um número porque eu já soube esse número alguém da Google me falou esse número mas por trás da Google Cloud da Google Cloud Platform quase todas as requisições que acontecem lá são através de RPC, pra vocês terem uma ideia. Quem aqui já ouviu falar no Open Telemetry? Tá? Quem aqui já ouviu falar no Open Telemetry, né? No projeto da CNCF pra parte de observabilidade e etc? Quem trabalha com Open Telemetry e já trabalhou com o bendito coletor,ito o collector, que fica pegando os dados de telemetria qual é o padrão principal para você trabalhar com esse cara? gRPC se você ver as novas integrações de API Gators todas suportando gRPC então pessoal, o ponto é o seguinte existem tecnologias que você não só tem que saber que existe se você tiver no contexto que você está usando o REST pra tudo tá? com certeza você pode tá? tá gastando tempo e dinheiro porque pode ser que existam outras soluções uma outra coisa que eu quero trazer aqui pra vocês também gastando tempo e dinheiro, porque pode ser que existam outras soluções. Uma outra coisa que eu quero trazer aqui pra vocês também sobre gRPC, antes de a gente mudar pra outro aspecto aqui, é a parte de stream bidirecional. O que que acontece, galera? Quando a gente trabalha com a maioria das tecnologias no dia a dia, normalmente a gente manda uma request e recebe uma response. Agora, muitas vezes, a gente está trabalhando com tecnologias que ficam processando dados o tempo inteiro. Então, imagina que eu tenho que te mandar uma informação que ela tem, sei lá, um giga de tamanho. Eu vou te mandando esses blocos, aí eu tenho que sei lá, 1 giga de tamanho, e eu vou te mandando esses blocos, aí eu tenho que esperar todo esse 1 giga chegar para o meu lado para eu processar, para eu te mandar de volta não sei mais o quê. Agora, você já imaginou eu ter a possibilidade de enquanto você está mandando esse 1 giga para mim, eu já vou recebendo as suas informações, já vou processando, e conforme eu já vou tendo o resultado, eu já vou retornando pra você o que eu já processei com a mesma conexão aberta. Tá? Galera, se você trafega muito dado de um lado pro outro, e esses dados precisam fazer um processamento pra retornar pra alguém, ou seja, cara, de forma bidirecional, você também pode tirar pra caramba proveito nesse caso aqui de gRPC. Tem gente que está confundindo o que eu estou falando de stream bidirecional com WebSocket. Não. Não tem nada a ver o WebSocket. Não. Não tem nada a ver com o WebSocket. O WebSocket é um outro tipo de protocolo. Ele é um upgrade do HTTP quando você estabelece uma conexão entre client e server daquela forma. O que eu estou dizendo aqui é que com o gRPC você consegue trafegar dados binários utilizando o protocol buffer. Esses dados, eles são feitos de forma bidirecional ou de forma unária também, ou seja, eu posso mandar stream só de um lado e no fim receber uma response, ou eu posso mandar uma request só e receber várias responses, ou eu posso mandar vários dados recebendo vários dados. Então, a grande sacada aqui desse cara é que você tem todas as vantagens de um request e um response comum que você tem no REST, mas você tem a opção de mandar dados e enquanto você recebe esses dados, alguém já vai processando e retornando ou eu posso mandar vários dados e depois que o outro cara recebeu todos, ele retorna, sei lá, a resposta pra ele, tá? Então, o que eu tô dizendo aqui, galera, é que com uma implementação muito, mas muito simples mesmo, você é capaz de ter esse tipo de solução. Tá? Então, hoje em dia, o que mais a gente tem é trafegar, não é só dados, é stream, basicamente, né? Ou seja, um conjunto de dados. A gente está trafegando o tempo inteiro array de bytes para lá e para cá. Certo? O que eu mais vejo é o quê? Grande latência pelo fato que você manda uma requisição, você recebe, você fica processando, depois você dá um response. Se você já consegue ir processando enquanto você está recebendo e depois retornar, nem que seja uma response simples, a velocidade que isso vai trabalhar vai ser muito maior. Então, galera, estudem com carinho esse cara aqui. Porque se você quer fazer comunicação entre microserviços de uma forma muito rápida para chamadas síncronas, cara, GRPC é algo que você não pode ignorar. E eu vou ainda mais longe, tá? Eu não acho que GRPC, fazer qualquer coisa usando GRPC, é mais complexo de fazer com HTTP. Na realidade, é que a gente está tão acostumado a trabalhar com REST que quando você vai aprender algo, qualquer coisa diferente de REST, você vai ter uma curva de aprendizado. Talvez se você tivesse aprendido GRPC desde o início, quando você fosse trabalhar com REST, você achasse até REST um pouquinho difícil. Então esse aí é um grande ponto. Tem gente fazendo algumas perguntas. Tem alguma alternativa grande no mercado para o GRPC? Eu não sei o que o Caio quis dizer. Mas, cara, honestamente eu não sei o que você quis dizer. Alternativa ao GRPC. Cara, as principais formas de protocolo de comunicação são esses que eu coloquei, mas tem alguns outros protocolos de serialização de dados que eu vou falar um pouco aqui depois pra vocês. O Danilo falou, faz sentido pra monolito? Cara, a questão não é se é monolito ou não. Se eu tenho o sistema A conversando com o sistema B, e esses sistemas conversam pra caramba com alto tráfego e eu quero diminuir essa latência, o gRPC pode servir normalmente. É independente se é monolito, isso aí é simplesmente um detalhe, tá bom? então esse aí é um ponto importante pra vocês conseguirem colocar beleza? agora pessoal, pra gente não ficar falando o tempo inteiro só de gRPC mas normalmente eu bato muito nessa tecla e a tecla que eu tô querendo colocar é independente do gRPC o grande chacoalhão que eu quero dar, de forma geral, é pare de rodar as coisas no piloto automático. Não é porque está tão tudo certinho como você faz a sua API, daquele seu jeitinho, que talvez, em determinados momentos no seu sistema, na solução que você está desenvolvendo, aquilo tem que ser daquela forma. Aquele ditado lá, né? Como é que é a parada? Toda vez eu confundo. Quando você só tem um martelo, qualquer coisa vira prego. Alguma coisa desse tipo, né? Normalmente tem um ditado. E é o que acaba acontecendo com a gente quando a gente está falando de REST, tá? gente, quando a gente tá falando de REST, tá? Mas, a gente começa a entrar em outras situações onde a gente precisa de comunicação assíncrona. E é aí que a gente tem que tomar um outro cuidado aí pra caramba, tá? Que é o seguinte, o lance é o seguinte, galera, se existe uma forma de você tentar minimizar a chance de você perder mensagem, comunicação entre sistemas, é trabalhar de forma síncrona. Eu imagino que todos aqui já devam ter ouvido falar em filas, em mensageria, tópicos, queue. Devem ter ouvido falar em ferramentas como RabbitMQ, Apache Kafka, ActiveMQ, Amazon SQS e etc. Mas a grande sacada que eu quero trazer aqui é o seguinte, normalmente, e eu vou mostrar isso pra vocês hoje no System Design, escutem o que eu tô falando, eu vou mostrar isso pra vocês no System Design, as pessoas, temem o que eu tô falando, eu vou mostrar isso pra vocês no System Design. As pessoas, tem gente aqui marcando a minha tela de novo, galera. Leonardo, dá uma olhada aí pra só eu poder mexer na minha tela, por favor. Então, o que que acontece? Nós desenvolvedores, a gente tem uma mania muito grande, tá? Ou a gente faz tudo um REST, ou depois eu falo que REST é ruim, daí todo mundo faz só usando o GRPC. Daí eu falo, mas você pode perder mensagem trabalhando de forma assíncrona. Aí a galera quer trabalhar com fila, só com fila, tá? Então essa é a ponderação que eu quero trazer aqui pra vocês, tá? Normalmente, quando você precisa de resiliência, ou seja, garantir que o seu sistema ele consiga continuar funcionando, mesmo em momentos de dificuldade, trabalhar de forma assíncrona, normalmente, ela ajuda muito, tá? Alguém aqui consegue me dizer o que é resiliência? O que que eu quero dizer com resiliência? Quem quiser falar, pode levantar a mão e daí o Leonan abre o microfone para você. Eu vou pegar o primeiro que está na lista aqui, tá? Mas tem que estar com câmera, tá, galera? Tem que estar com câmera. Tem o Christian. Aí, Christian, você que tá no primeiro da fila aí, cara, explica pra gente, dá uma aula aí pra gente sobre o que você entende como resiliência. Beleza, tá me ouvindo? Perfeito. Boa noite, pessoal. Obrigado pela oportunidade. O que eu entendo é resiliência. Resiliência é quando a gente tem um objetivo, pode ser uma persistência, pode ser um fluxo de informação, pode ser ações ou eventos que vão fazer alguma coisa mais assertiva, sei lá, concluir a compra de um produto na internet. Então, o fato daquilo ser resiliente deveria ser como se fosse formas daquela situação sempre ser concretizada. Não sei se eu consegui passar claro. Por exemplo, o objetivo de e-commerce. A parte mais importante e deveria ser focada na resiliência é a parte da finalização de compra. Aquela lei é muito importante para o negócio. Perfeito. Vamos lá, então. Eu vou tentar juntar a resposta do Christian com normalmente como normalmente eu tento explicar. O que o Christian falou, no final das contas, é como que eu consigo ter garantia e aquilo que é pra ser feito, vai ser feito. Então, o que você mais falou, Christian, nesse ponto é conseguir ter garantias de que uma transação ou alguma ação, naquele momento, ela realmente vai ser concluída. Então, quando você, em tese, tem resiliência, você consegue ter essa garantia. Agora, o grande ponto da resiliência, você consegue ter essa garantia. Agora, o grande ponto da resiliência, normalmente eu trato como se fosse uma árvore. Imagina que essa parada aqui é uma árvore, certo? Aí, o que acontece aqui? Eu começo a ventar. Coloca um monte de chuva e vento aqui nessa árvore. Essa árvore tem duas opções aqui. Ela tentar ficar o mais rígida possível para ela não ser afetada por essa chuva aqui para mim. Quando a chuva é muito forte, e se essa árvore ficar rígida dessa forma, o que vai acontecer com ela? Ela vai quebrar. Simples assim. Essa árvore, ela vai quebrar. Agora, se eu tô tendo muita chuva, muito vento, pra que essa árvore não quebre, o que naturalmente ela começa a fazer? Ela começa a se dobrar. Ela está no estado comum dela aqui nesse momento? Ela não está. Ela vai conseguir estar no seu estado natural. Você acha que ela está de boas? Estou toda torta aqui, estou tudo ferrado, um monte de vento. Eu gostaria de continuar assim para sempre? Não. Com certeza ela quer voltar ao estado natural, tanto que, em tese, ela volta depois. Mas o principal ponto aqui é que essa árvore não quebrou. Porque se ela quebrasse, ela ia simplesmente deixar de ser uma árvore naquele momento. Ela seria uma árvore quebrada e ela seria entre aspas naquele momento inútil pra gente. O que que a gente começa a tratar quando a gente fala de resiliência? É exatamente isso aqui. Imagine o nosso sistema como uma árvore. Muitas vezes o nosso sistema recebe um monte de requisição. Acontece um monte de coisas que a gente não está esperando. O nosso sistema, ele pode fazer o quê? Ele pode tentar ficar de pé da forma como ele deveria estar e daí simplesmente ele fica 100% indisponível. E acabou a brincadeira por aí. A brincadeira simplesmente acabou. Acabou o play. O sistema caiu. Zerou pra todo mundo. Ou seja... Pode até envergar, só não pode cair, né? Exatamente. Qual que é a sacada da resiliência? É o nosso sistema conseguir fazer isso. Ele vai funcionar no seu estado natural? Ele não vai. Mas, tá? Existe uma parada que a gente chama de graceful degradation. Vocês já ouviram falar nisso? Graceful degradation significa que, apesar de eu não estar funcionando com todas as minhas capacidades, pelo menos essas operações ainda, eu consigo processar e trabalhar. Basicamente isso que Graceful Degradation faz. É a garantia, né? Mais ou menos uma espécie de garantia, porque pode estar partes desse sistema que naquele momento ele não fique realmente disponível. Saca? Ou seja, pode haver algum tipo de indisponibilidade. Mas o grande ponto é que independente disso que aconteceu, quando a chuva passar, ele não quebrou, ele vai voltar ao normal e ele vai conseguir fazer tudo que ele deveria fazer agora, mas ainda ele vai conseguir fazer tudo que ele deveria ter feito enquanto ele estava fora do ar. Se eu tenho um sistema de e-commerce que cai a parte de pagamento na hora da pessoa concluir e essa parte fica vermelha, acabou o play galera, ninguém vai conseguir concluir a compra se eu tô com esse sistema com problema aqui mas de alguma forma, eu penso nossa, deixa eu então, ao invés de depender desse cara direto deixa, sei lá, eu colocar uma pequena fila pra proteger um pouco mais essa operação, já que ela é tão importante. O que que vai acontecer aqui? Por mais que tenha um caminhão de situação aqui, o meu sistema fique fora do ar nesse momento, o que que vai acontecer? Os dados, eles vão ficar aqui. Quando esse sistema falar nossa, né, a brisa tá passando, tô ficando de boas e etc., o que que vai acontecendo? Ele vai voltando, voltando, voltando e ele continua a fazer aquilo que ele deveria tá fazendo, tá? Eu tô usando um exemplo de uma fila, tá? Mas existem inúmeras formas, até mesmo desse próprio sistema, conseguir ter uma área dele somente para pre garantir ou indicar a resiliência? Eu posso usar diversos patterns para me ajudar. E para eu comunicar para Deus nesse momento, pare de mandar chuva que eu vou quebrar. Que é o quê nesse momento? Sei lá, eu coloco aqui um circuit breaker. Né? Tá? Uma quebra de circuito o que esse cara vai fazer? estou recebendo muita requisição não vou aguentar então eu vou fechar a comunicação e conforme eu vou recebendo as requisições eu vou voltando ao normal então normalmente quando a gente está falando em resiliência de sistemas a gente está falando em resiliência de sistemas, a gente está falando no quê? Exatamente no que o Christian falou. Fazer com que aquela ação consiga ser concluída de alguma forma. Nem que ela demore mais para ser concluída. E aí entra aquele momento de negócio. Por exemplo, para algumas empresas pode ser aceitável eu mandar a solicitação de pagamento para uma fila e quando o sistema estiver disponível ele realiza a processamento do pagamento e depois avisa o cliente. Para alguns negócios, não. Eu quero que o cara clique e receba pagamento e depois avisa o cliente. Para alguns negócios, não. Eu quero que o cara clique e receba pagamento aprovado. Então, esse aí é um... São decisões de negócio. A grande questão é que o nível de resiliência que o seu sistema vai ter, ele vai depender do nível de complexidade e de criticidade que a sua aplicação vai ter. Então, são esses pontos que eu quero que vocês tenham em mente. E a melhor forma de você começar a perceber esses tipos de coisa é o seguinte. Pegue alguns sistemas que vocês têm hoje com microserviços e etc. Se você tirar aquele microserviço X fora do ar, o que vai acontecer naquele momento com aquele sistema? Tá? Então, isso aí é um ponto importante aí pra vocês conseguirem se ligar. Se esse sistema estiver fora do ar, eu vou perder transação? Não sei. Quando ele voltar no ar, aquelas transações que ele não conseguiu processar, ele vai conseguir processar depois? Então, a questão aí é o seguinte, trate cada request no seu sistema como um pique de um milhão de reais. Se o seu sistema estiver fora, perdeu um milhão. Se você começar a pensar dessa forma, com certeza você vai pensar, como que eu vou fazer agora para esse milhão não ser perdido nesse tipo de situação? Mas vão ter situações que eu vou falar, a empresa vai querer pagar um milhão nessa situação, porque para manter essa parada resiliente dessa forma ela vai gastar 100 milhões de reais por mês pra conseguir manter todo esse arcabouço resiliente da melhor maneira possível tá? então não tem almoço grátis a realidade de qualquer coisa que a gente tá falando é essa então toda vez que você pensar em resiliência, pensa aquele ditado, nós enverga, mas não quebra. Como que você consegue envergar o seu sistema de uma forma que ele não vai perder informação e quando ele voltar no ar, as coisas ainda vão estar funcionando. Existe um termo muito comum que é chamado de self-healing. Esse termo é de autocura basicamente é aquele sistema que se você der um tempo pra ele abrir o circuito e dar o tempo pra ele se recuperar ele vai voltar ao normal em pouco tempo ou seja, sistemas que conseguem se autocurar então a minha pergunta e novamente, e eu acho que muito daurar. Então, a minha pergunta, e novamente, e eu acho que muito da aula de hoje que a gente vai fazer aqui, galera, é ter esse nível de reflexão. Muitas vezes o que eu estou falando para vocês é óbvio, mas sabe aquela parada óbvia que é óbvio, mas você não faz? É óbvio, mas você não reflete? É óbvio, mas você não revê como é que está hoje os sistemas que você está trabalhando. Então, eu acho que é uma boa checklist para vocês levarem em consideração na hora que a gente está trabalhando principalmente com sistemas distribuídos. Uma forma que uma forma de que a gente pode ter mais resiliência, normalmente nos sistemas, é colocar caras intermediários para se comunicar entre sistemas. E aí a gente fala normalmente de mensageria, comunicação assíncrona. Eu tenho o sistema 1 falando com o sistema 2, mas eu tenho um intermediário aqui no e-mail. Aqui no meio, né? Aqui no e-mail, não. Eu tenho esse cara intermediário aqui. Então, se esse cara estiver fora, a mensagem desse cara vai estar gravada aqui e não vai ter nenhum problema. Quando esse voltar, ele consegue processar. Esse é o conceito simples que a gente tem de mensageria entre sistemas. Comunicação entre sistemas. Normalmente esses caras aqui são message brokers. Ou seja, são caras especializados em conseguir trafegar dados de um sistema para o outro. Basicamente é isso que acaba a trabalhar. Beleza? Então isso é um ponto importante. O Clayton colocou aqui uma pergunta interessante. Dúvida. Colocar uma fila na frente não pode trazer um risco de causar indisponibilidade de acordo com o problema na fila. E aí é uma pergunta interessante. Se eu tenho um sistema de mensageria e se esse meu sistema de mensageria cair, o que que acontece? Eu vou perder todas as mensagens? Novamente, é o nível de risco que você pode aceitar ou não, tá? Normalmente, se você tá trabalhando com um sistema de mensageria, esse sistema ele é tão específico e normalmente ele trabalha de forma muito distribuída ao ponto de que mesmo que partes ou clusters deles fiquem fora do ar, ele ainda vai continuar no ar, tá? Se você pegar um cáfica da vida, ele trabalha de forma extremamente distribuída exatamente pra evitar esses tipos de problemas mas vamos aí ser um cara totalmente pessimista, que nem o nosso amigo colocou aqui. O que acontece se esse meu cara aqui cair no meio da história? Aí você pode fazer coisas básicas, existem alguns padrões que você pode utilizar. Por exemplo, eu posso colocar um banco de dados aqui. Aí todas as mensagens que eu vou mandar para o sistema X, eu vou armazenar todas elas aqui antes. Aí, depois que eu fizer isso, eu vou mandar as minhas mensagens, né? Que eu estou mandando daqui para cá. E aí, quando esse sistema daqui garantir que a mensagem foi entregue, eu venho aqui e apago essa mensagem do banco de dados. Isso aqui, normalmente, é um padrão. A galera chama Outbox Pattern. Outbox. É uma outra forma de você garantir que se esse cara estiver indisponível, ainda assim eu não perdi o meu Pix. Essa que é real. Agora, você vai implementar isso em todos os seus micro serviços? Você não vai. Novamente, galera, depende do contexto, do nível de criticidade do sistema que você está utilizando. Vai ter sistema que você não vai usar fila porque você acha que não há necessidade, você coloca algumas políticas de retry ali e etc. Vai ter sistema que você vai usar só fila, vai ter sistema que você vai trabalhar com outbox, vai ter sistemas que você vai trabalhar com outbox e vai criar um job de retry sem usar fila e vai usar o seu próprio outbox como se ele fosse um sistema de mensageria. Tem para todos os gostos. A realidade é essa, tá? Mas o grande ponto é que toda vez que você vai projetar um sistema, você tem que analisar o nível de risco daquele tipo de serviço e ficar fora do ar. E, novamente, esse tipo de definição não é só uma definição técnica, é uma definição de negócio. E é por isso que o desenvolvedor, entendendo esses níveis de risco, ele tem que conseguir levar isso para alguém da área de negócio, para a área de produtos e etc. Falando, a gente tem essas possibilidades. Essa possibilidade custa X, essa Y, essa Z. Qual você quer, me fala que eu implemento. Agora, qual que é o grande ponto que é o que a gente estava falando no início do nosso bate-papo, galera? O ponto é que se você nunca ouviu falar nisso, se você nunca ouviu falar nisso, se você nunca ouviu falar nisso, se você nunca ouviu falar nisso, você nunca ouviu falar nisso, você não consegue dar essas opções. Porque você não sabe que você não sabe essas coisas. Esse aí é o grande problema, tá? Então, fica aí a dica. Para a gente andar mais rápido, galera, existem algumas formas bem padrão de você conseguir se comunicar através de forma assíncrona com esses tipos de sistema. Uma forma muito comum é através de filas que na realidade indica você guardar algo num sistema e o outro sistema fazer o consumo dessas mensagens. Existe uma outra forma muito comum que a gente chama de PubSub, que eu acabei de colocar aqui. O PubSub basicamente é, eu tenho um cara que está interessado em tal mensagem. Então, basicamente, eu tenho o Wesley, ele vai produzir uma mensagem para esse cara aqui. Vamos colocar aqui rapidinho só pra a gente seguir a linha de raciocínio. E eu posso ter aqui o Pedrinho, o Zezinho, o Luizinho, escutando exatamente essas mesmas mensagens aqui pra mim, tá? Então, é como se fosse um broadcast. Sintoniza no rádio tal. Todo mundo que está escutando aquela estação de rádio vai receber aquela mesma mensagem. Não interessa quantas pessoas estejam conectadas. Todas vão receber exatamente a mesma mensagem. Então, esse cara aqui é o publisher e esse cara aqui é o subscriber e esse aqui é o tópico onde você vai ficar escutando aquelas mensagens, tá? Então, esse aí é um ponto, assim, importante de a gente conseguir trabalhar, beleza? Subscriber. Existem diversas tecnologias que trabalham dessa forma. O Kafka trabalha com tópicos usando o padrão PubSub. O Redis tem PubSub. O Postgres tem PubSub. Então, tem diversos formatos pra você conseguir trabalhar nesses tipos de coisas. É importante somente pra gente relembrar. Tem outros caras que trabalham de forma similar, tá? Mas que não usam necessariamente esse tipo de padrão, que é os caras que trabalham com exchanges no meio da história, que no caso aqui, o mais comum, o mais conhecido é o RabbitMQ. O RabbitMQ, basicamente, o produtor, ele sempre vai enviar mensagem para um hub de informações. Ou seja, para um roteador. Nessa mensagem, vai ter alguns metadados. E baseado nesses metadados, esse cara aqui baseado nesses metadados esse cara aqui sabe pra qual fila de mensagens os dados devem ser enviados tá? então eu posso mandar uma mensagem num padrão e essas dois caras vão receber agora se eu mandar uma mensagem num outro padrão vai ter um outro cara aqui que vai receber essa mensagem, mas esses dois caras não vão. E as mensagens foram enviadas pro mesmo cara. Tá? Então, essa é uma outra forma muito inteligente, inclusive, de você conseguir organizar as coisas. Porque não fica todo mundo pendurado no mesmo tópico. Todo mundo acaba ficando pendurado apenas nas filas que eles têm um super interesse e não vão ficar recebendo, eventualmente, dados que não interessam a eles, por conta que eu tenho um roteador que acaba filtrando um pouco esses tipos de coisa. Então, essa é uma opção super bacana e funciona. Milhares de sistemas no mundo inteiro utilizam esse tipo de cara. Eu utilizo esse tipo de cara, funciona muito bem, sou muito feliz com ele, adoro o coelhinho nesse caso aqui, no caso do RabbitMQ, tá? De uma forma ou de outra, é importante saber que, independente disso, existem formas de comunicação. Mas, no final das contas, tudo é variação de quê? Vai ter um intermediário que vai receber uma mensagem e o outro cara que vai ler essa mensagem desse intermediário para que você não perca essas mensagens. Agora, por último, antes de a gente voltar para o System Design, e daí eu vou trazer algumas opções aqui para vocês, eu quero falar rapidinho sobre dois caras importantes que a gente acabou falando no início quando eu falei de comunicação bidirecional via GRPC, que são os WebSockets. Cara, WebSockets, assim, na minha opinião, é uma das mil maravilhas do mundo. Porque por muitos anos, eu trabalhei com diversas soluções quando WebSockets não existiam. E, cara, era o caos tentar fazer comunicação em tempo real. Principalmente porque a coisa mais relativa do mundo é o que é tempo real. O que é tempo real pra você? É você receber uma requisição em 1 milissegundo, em 10 milissegundos, a cada 1 minuto, a cada 30 segundos. O que é tempo real? Tempo real é... Eu fechei o olho, abriu, saca? Então, a gente tem que tomar cuidado dessa parada de tempo real. Na realidade, eu quero trocar esse tempo real, ressignificar esse tempo real com uma outra coisa. Eu quero ressignificar isso como conexão persistente. Tá? Ou seja, quando eu abro um túnel de comunicação com uma outra ponta, e uma ponta manda uma informação pra outra, eu tendo a receber essa mensagem diretamente. Tá? Eu não preciso ficar abrindo toda hora uma conexão. Imagina que eu tô falando no telefone. Eu disco o seu número, você atende e eu falo, oi. Aí eu desligo e você desliga. Daí você liga pra mim e fala, eu atendo, tudo bem? Daí você desliga, eu desligo e eu atendo, tudo bem? daí você desliga, eu desligo eu respondo, tudo bem cara, isso é o que a gente faz com REST, no final das contas, com comunicação síncrona, cada link que a gente faz, você liga a pessoa atende, você desliga, a pessoa atende de novo e a gente fica dessa forma, o tempo real na realidade, o que ele traz aqui pra gente é o seguinte, eu vou ligar, mas não desliga a outra ponta aí, tá? Vamos conversar. É basicamente isso que acaba acontecendo quando a gente tá falando, nesse caso aqui, com o WebSockets, tá? A grande sacada do WebSockets é que ele mantém uma conexão persistente, tá? Entre client e server. E o mais interessante é que essa conexão persistente, tá? entre client e server, e o mais interessante é que essa conexão persistente ela vem através do HTTP, feito um fazendo um upgrade na requisição, eu quero que vocês façam um experimento e depois me mandem, quem aqui já trabalhou com WebSockets? tá? quem aqui já trabalhou com WebSockets? Agora, quem aqui já analisou todos os logs de todo o acontecimento de uma requisição até a conexão com o WebSockets ficar estabelecida? conexão com o WebSockets ficar estabelecida. Quem aqui conseguiu já ver todas as mensagens que acontecem ali na hora que está tendo o handshake e tudo mais? Recomendo que todos façam isso, tá? Acabou aqui, antes de vocês contratarem um MBA, não, depois que vocês contratarem um MBA, tá? Vocês vão fazer isso aqui, galera. Façam uma conexão via WebSockets e analise todos os logs do que acontece. Vocês vão perceber que são bem interessantes. Você faz uma requisição do HTTP, você faz uma solicitação de um upgrade pra trabalhar com WebSockets. É feito basicamente esse upgrade e você fica com uma conexão TCP aberta. É muito louco de como essas coisas acabam funcionando, esse tipo de handshake. Então, a inicialização da conexão começa via HTTP, mas é feito um upgrade no protocolo no meio do caminho. Então, isso aí é interessantíssimo vocês conseguirem se ligar. Grande sacada do WebSocket é você possibilitar cliente e servidor mandarem mensagem. Comunicação ali, bidirecional. Agora, por outro lado, existe uma outra situação. E é, novamente, aquele outro tipo de coisa que muita gente não sabe que não sabe e daí acaba usando WebSockets pra tudo. Por exemplo, quem aqui sabe o que é Server Sent Events, ou o famoso SSE? Quem conhece, fala sim, quem conhece, fala não. Tá? Caras, lance o seguinte, SSE, trabalhar com esse cara é ridiculamente simples é muito simples trabalhar com esse cara, tá? e o que eu acabo vendo, as vezes você cria aquele dashboard bonitão você precisa que o seu dashboard atualize em tempo real vamos dizer assim, né? e daí, o que você vê um monte de dev fazendo? Fazendo uma conexão via WebSockets para pegar esses updates em tempo real, porque você sabe que você tem que manter uma conexão persistente. E uma forma de manter uma conexão persistente é com WebSockets. O grande ponto é que o seu dashboard não vai mandar nada para o server. É só o server que está mandando informação para o seu dashboard boladão que você está criando. O server-centered events serve exatamente para isso, galera. É uma comunicação em tempo real, ou seja, com uma conexão persistente de unilateral, onde só o servidor envia o dado. Então, se você realmente precisar de comunicação bidirecional, você vai sim poder utilizar o WebSockets. Agora, se você precisa apenas ficar mandando dados para o client, cara, você não precisa do WebSockets. Tem uma forma muito mais simples de você fazer, é super tranquila, vai gastar menos recurso e você vai estar muito mais feliz, tá? Então, é muito importante vocês entenderem esses caras. Galera, eu conheço muito cara sênior, sênior, sênior, sênior mesmo, que não conhece SSE. E... E algo muito bobo, tá? Bom, bobo entre aspas, tá? O que eu estou querendo dizer é que a gente faz coisa muito mais complexa e às vezes algo que, obviamente, por trás dos panos é complexo, a gente acaba não usando porque a gente desconhece, tá? Então, essa pegada é importantíssima para você conseguir trabalhar, tá? Então, tem gente perguntando, o SSE é para notificar o front-end, tipo um push notification? Mais ou menos, basicamente, o seu front-end vai estar conectado, né? Vamos dizer, num endpoint, e cada hora você vai ficar recebendo uma mensagem nova. E daí, toda hora que você receber essa mensagem nova, você faz atualização no seu front-end. É muito simples mesmo, galera. Tá? É muito simples mesmo. Tá? Como escalar horizontalmente usando WebSockets? Cara, aí a gente entra numa outra seara. Se tem algo complexo nesse mundo, tá? É trabalhar com WebSockets em larga escala. Porque você tem que manter trilhões de conexões e você vai ter que, quando você escala horizontalmente, você vai ter diversos servidores segurando essas conexões. O que você vai ter que ter é um hashing, claro, do client e server para eles sempre ficarem apontados para o mesmo servidor. Basicamente, a ideia principal é essa, tá? Existem diversos serviços gerenciados de WebSockets que facilitam a sua vida pra você não ter que ficar se matando com isso, tá? Agora, pro último, pra gente acabar com essa pegada toda, eu quero falar com você sobre Protocol Buffers e Flat Buffers, tá? O Protocol Buffers é o cara que a gente utiliza no gRPC, tá? Ou seja, ele é um arquivo binário, onde ele tem uma especificação, um arquivo .proto, tá? E nesse arquivo, ele é serializado, transformado em binário, e é enviado para outro sistema, independente do meio, no caso de RPC vai via HTTP, mas não precisa ser via HTTP, e o outro cara lê esse cara, baseado numa especificação, ou seja, no arquivo .proto, deserializa essa informação, e consegue utilizar os dados se você perceber eu utilizei a palavra serialização e deserialização da mesma forma como acontece com o JSON eu transformo o texto numa espécie de um objeto pra eu enviar os dados e depois eu tenho que pegar aquela parada e deserializar Transformo o texto numa espécie de um objeto para eu enviar os dados, e depois eu tenho que pegar aquela parada e desserializar e transformar de novo. Qual é a grande vantagem do protocol buffers? É que, apesar de haver serialização, essa serialização é gerada através de um arquivo binário. Serializar e desserializar as informações em binário é mais rápido do que em arquivos texto. E o resultado do arquivo é muito menor. Então, esse aí que é o grande ponto. Mas perceba o seguinte, tá? Mas perceba o seguinte. Quando eu estou falando de protocol buffers, ainda existe serialização. Você não foge da serialização. Ela é muito mais rápida do que serializar arquivos texto, como um JSON da vida. É infinitamente mais rápido e por isso que gRPC é utilizado muito fortemente em sistemas de grande concorrência. Por outro lado, ainda há serialização. Existe uma outra tecnologia também da Google chamada Flat Buffers, tá? E essa sim, ela é menos utilizada. E ela é menos utilizada por quê? Tá? Porque, de fato, a curva dela é um pouco mais chata de você trabalhar não é difícil, tá? eu já fiz várias POCs, diversas coisas, eu nunca trabalhei em um sistema só pra deixar claro também aqui pra vocês tá galera? eu nunca trabalhei em produção com um sistema usando flat buffers, tá? só pra vocês saberem, mas a grande sacada aqui do flat buffers é o seguinte. No FlatBuffers, não há serialização e deserialização. Ok? O que acontece com o FlatBuffers é mais ou menos isso aqui, galera. Imagina que eu tenho um buffer. Legal? Eu tenho esse arquivo .fbs que é a especificação desse cara e daí eu vou falando o seguinte, olha, eu quero gravar uma string aqui, depois aqui eu tenho um inteiro, aqui eu tenho outra string, aqui eu tenho mais uma string, tá? Ou seja, dentro de um buffer de dados eu tenho os meus offsets eu sei que da casinha 0 a 9 é uma string que tem a informação de nome eu sei que da tal a tal lugar é e-mail eu sei basicamente baseado na especificação, aonde estão os dados. Então, o que acontece no caso do Flat Buffers? Eu não serializo a informação. Na realidade, não é que eu não serializo a informação. Eu acabo serializando a informação colocando essa informação dentro de um buffer. Ou seja, é um array de bytes. A real é essa. Baseado num array de bytes, eu mando para um outro sistema. Esse outro sistema, baseado nessa especificação de um arquivo .fbs, ele fala, ok, recebi um buffer agora, eu preciso do nome. Ah, o nome está na posição tal. Ele vai lá nome ah, o nome está na posição tal, ele vai lá e lê o nome eu não sei se vocês conseguiram entender a diferença mas nesse caso não há deserialização eu vou e pego apenas o dado que eu estou atrás dentro daquele buffer tá, então imagina um array de bytes onde eu sei a posição onde está cada informação, e ao invés de eu pegar aquele array gigante e gerar um objeto, né, pra popular uma classe minha, eu não faço isso, eu falo, me dá um nome. Ele retorna o nome. Aí se eu vou botar esse nome numa classe ou em qualquer lugar, aí é problema meu. Mas a grande sacada aqui nesse caso é que não há o trabalho de deserialização. E para que isso é importante? Galera, se você tira da história de serialização, se você tira da história, você lê somente o dado que você quer e não precisar de serializar outros dados que você nem iria utilizar, isso aí, tá? Acaba sendo muito, muito melhor. Então você vai ter o dado em binário, da mesma forma como você tem no protocol buffers, mas a principal diferença é que não há de ser realização. E eu só pego a informação que eu preciso. Ou seja, é muito mais rápido. E se é muito mais rápido com baixa latência, um monte de gente descobriu que trabalhar com esse cara nos games é bom pra caramba. Então, se você pegar uma pancada dessas engines de games hoje em dia, você vai ver que a forma de como eles se comunicam pra pegar dados de um pedaço do jogo, jogar pra outro, pra os dados processarem, pra fazer isso, pra fazer aquilo, um dos principais protocolos pra essa comunicação é utilizado em flat buffers porque usa menos recurso computacional. Galera, qualquer coisa que a gente falar em serializar e desserializar tem um pico de CPU porque é processamento mesmo pra você pegar um conjunto de bytes e transformar ele em um objeto da sua linguagem de programação. Se você não precisa fazer essa transformação, é muito mais rápido. Então, o FlatBuffers, você só lê o que você precisa e você não precisa sair convertendo o objeto para nada. Então, essa que é a grande sacada. Beleza? Galera, saindo de protocolos, eu quero falar com vocês sobre o que a gente viu especificamente ontem, que foi o nosso system design, deixa eu acho que é esse cara aqui, que foi aqui que a gente parou. A nossa ideia ontem era cumprir esse system design do Uber. Se você perceber aqui, o que eu acabei fazendo e mostrando aqui para vocês é não me preocupei com absolutamente nada de formatos de comunicação a única coisa que eu fiz aqui foi fluxos na ordem que as requisições elas podiam acontecer com certeza se eu fizesse algo parecido com isso numa entrevista provavelmente eu ia ser promovido pra júnior certeza que se eu fizesse algo parecido com isso numa entrevista, provavelmente eu ia ser promovido pra júnior. Ou não ia passar na entrevista. A real é essa. Porque, basicamente, o que eu fiz foi um monte de linha com fluxo de informações batendo em vários lugares aqui e que eu pintei com cores diferentes pra ficar melhor de eu tentar visualizar o caminho de cada requisição. Então, se tem uma forma que você não deve fazer um system design, é dessa forma aqui. Porque qualquer coisa que você bate o olho e pareça confuso, você pode perceber que se tá confuso pra você, imagina pra outras pessoas. Então, começa por aí. Mas, de uma forma ou de outra, a gente conseguiu pensar em alguns pontos importantes. Por exemplo, eu tenho um API Gateway aqui na frente. Ou seja, ninguém consegue ver da porta para dentro da minha casa. Ninguém que está lá fora precisa saber os serviços que eu tenho. Um API Gateway aqui pode tratar de autenticação, dependendo da situação autorização, ele pode ter regras de rate limiting, ele pode ter um trilhão de coisas. Antes de um API Gateway, eu posso colocar um WAF também, um Web Application File, tem diversas coisas que a gente pode trabalhar e a gente poderia ir num ponto mais aprofundado. Mas o maior ponto que eu quero trazer aqui pra vocês é da forma como as coisas estão apontadas aqui, tá? Seria o seguinte, tá? Ah, e galera, por favor, tá? Eu falei que eu ser promovido pra júnior, eu não tô colocando nenhum desenvolvedor que é júnior, tá? estou colocando nenhum desenvolvedor que é júnior no sentido pejorativo. Eu estou dizendo que se eu for promovido para júnior, eu estou querendo dizer que eu tenho 25 anos de experiência, estou aqui dando aula para sêniors e entrego um negócio desse. O máximo que vão falar é que um cara que está fazendo isso, no mínimo, ele é um júnior. Não tirando nenhum mérito de júnior. Todo mundo foi júnior um dia, e todo mundo que é júnior um dia vai virar pleno, vai virar sênior, vai virar tech lead, se Deus quiser vai virar um staff engineer, um CTO, o dono de uma empresa, não interessa, tá? Só para deixar bem claro, para não gerar nenhum tipo de mal-estar ou qualquer tipo de constrangimento, tá, galera? É basicamente isso que eu quis dizer. Agora, o grande ponto aqui que eu tô querendo trazer, pessoal, é o seguinte. Além da confusão dessas setas, né, de tudo isso que tá acontecendo, a gente tem um algo muito claro aqui. O que que é esse algo claro? Significa que se qualquer setinha dessa quebrar, o sistema inteiro acabou. Não existe mais sistema. Se eu tirar essa setinha aqui, nada mais funciona. A real é essa. Tudo que eu fiz aqui, uma setinha que aconteça, tá? Tudo que eu quero que aconteça, se uma setinha dessa quebrar, vai dar ruim. E o porquê? Porque quando você sai fazendo esses tipos de apontamento, nitidamente você tá trabalhando de forma síncrona e nitidamente você tá simplesmente fazendo flux forma síncrona e nitidamente você está simplesmente fazendo fluxos e o system design ele não ele não tem essa ideia a ideia do fluxo do system design não é apenas para dizer fluxo da informação e a ideia de um system design também não é apenas também para falar que existe uma fila para mostrar que o serviço é resiliente. A ideia do System Design é conseguir fazer com que a gente tenha entendimento do sistema, de quais componentes eles existem e como esses caras vão conseguir se conectar. eles existem, e como esses caras eles vão conseguir se conectar. Então, o nosso objetivo desse caso aqui é tentar fazer um pequeno upgrade nesse System Design. Mas na hora que a gente for fazer esse pequeno upgrade, eu também vou mostrar um outro System Design que ele é ruim por dois motivos principais, tá? E eu vou mostrar ele aqui abaixo, nesse momento, se é que eu tô com ele aqui. Aparentemente, esse System Design, ele é um pouco melhor do que o outro, tá? Deixa eu ver se todo mundo consegue enxergar bem esse cara aqui. Todo mundo consegue enxergar bem esse cara aqui. Todo mundo consegue visualizar bem esse cara? Eu acho que sim, né? Acho que tá de boas. Bom, galera, aqui com esse design, as coisas ficaram um pouco melhor, tá? Porque, nesse caso, se você olhar, eu tive um foco muito grande em evitar perder qualquer tipo de mensagem. Para que se eu tivesse algum problema naquelas setinhas, ou se eu tivesse uma indisponibilidade de qualquer sistema, eu ainda continuaria mantendo o sistema funcionando. Então, eu vou revisar o fluxo aqui com vocês, de todas as situações, e daí eu vou trazer aqui para vocês também o problema desse tipo, desse system design. Mas, antes de eu explicar isso, eu queria que algumas pessoas, vamos lá, duas pessoas, duas primeiras que levantarem a mão, criticassem isso que eu fiz. Onde que vocês acham que tem os principais problemas desse system design? Tem que estar com a câmera ligada. O Vitor levantou a mão. Bota a câmera aí, o Vitor. Opa, estou indo. Bota aí, Vitor. Show de bola tô me dando. Bota aí, Vitor, show de bola. Cara, mete a bronca, cara, manda ver, cara. Bom, do design que você tá mostrando, aparentemente, a parte de escrita e de leitura da sua aplicação tá acoplada. Então... Me explica um pouco melhor o que que é a parte de escrita e leitura da minha... Cara, eu juro que eu não entendi o que você quis dizer. Me dá um exemplo em um dos fluxos aqui. Eu acho que à medida que você fizer uma request, você... Você consegue dar um exemplo de uma, em qualquer request? Vamos pensar aqui, request fare estimate. Ou seja, o cara está pedindo o orçamento para ele ver quanto vai custar a viagem dele. Legal? Aham. Então, eu estou batendo aqui, request fare estimate. Esse cara aqui, provavelmente, nesse caso, ele vai bater aqui vai cair numa fila, pra eu não perder informação, então eu não vou perder o dado vai cair no meu serviço de ride vai aparecer aqui provavelmente, numa fila de ride request, ou seja publiquei a minha ride aqui aí eu vou ter um ride matching pra achar os motoristas, aí pra eu achar os motoristas, o que que depois disso o que que eu vou ter um ride matching para achar os motoristas. Aí, para eu achar os motoristas, depois disso, o que eu vou fazer? Eu vou pegar esse ride matching, mandar as informações dos caras que eu quero para fazer a minha ride. Vou pegar a localização dos meus motoristas aqui para mim. Vou pegar, tendo a localização dos meus motoristas, eu tenho as localizações aqui no meu response, esse meu ride matching vai pegar a localização dos meus motoristas, vai saber quem são os motoristas baseado nos meus motoristas ele vai mandar a resposta de quem são esses caras que estão perto de mim vai fazer o cálculo do frete de quanto que vai ficar a entrega, peguei a taxa, mandei numa fila, o ride vai ler essa taxa, vai atualizar essa taxa, e depois o que o ride vai fazer? Vai mandar uma notificação aqui pra uma fila, pra eu não perder os dados, o sistema de notificação vai notificar o rider falando, né, a estimativa de quanto que ficou aquela corrida. Qual que é o meu problema nesse caso aqui? É que eu pensei que esse notification tem muito a ver com se o cliente vai estar online na hora ou não, e ele não tem muito um caráter de leitura onde o cliente pode solicitar o dado, por exemplo, da última request que ele fez. Não, na realidade a gente está seguindo aqueles requisitos bem claros. O cliente solicita o preço da corrida, ele confirma a corrida, é enviado para o motorista, o motorista aceita ou não. Esse é o negócio, o cliente não tem outras consultas, esses são os nossos únicos três requisitos. Não, mas está... não vejo muitos outros problemas, não. Era mais... Daniel! Opa, desculpa te cortar, não, show de bola. Não, eu ia dizer só, era mais em comparação com o CQRS, onde a gente consegue dividir o lado de escrita e de leitura e criar, por exemplo, projeções, que são agregações dos dados, que a gente consegue persistir e entregar para o cliente de maneira tanto síncrona no sistema de notificação, quanto assíncrona, utilizando o banco de dados de leitura bem otimizado. É que nesse caso aqui, para mim é indiferente se eu estou trabalhando com CQRS, na realidade. CQRS acaba sendo um design dentro do meu software e da forma como eu vou gravar ou qualquer coisa desse tipo. Assim, nesse caso, CQRS aqui, eu poderia estar usando CQRS em qualquer um desses tipos de sistemas, ter mais um banco de dados, trabalhar com event sourcing, nesse caso aqui é meio que indiferente. Agora, fala aí o Daniel. O Daniel está com uma cara brava, ele vai acabar com o meu system design aqui. Não, não, foi mal. É que eu estava pensando aqui. Não, na real eu ia seguir mais o que você tinha comentado ontem sobre o nosso system design que a gente tinha feito. Então, eu senti falta ali das informações do que a gente vai ter nas sequestras, o que vai transacionar, ou pelo menos uma breve documentação disso nesse exemplo que você mostrou agora. E fora a questão dos domínios, que também eu não consigo ver separado se esses quadradinhos azuis, se eles são os domínios, se eles são os serviços. Então, esses são os principais pontos. Só para botar uma legenda, galera, só para deixar uma legenda clara, de qualquer forma, todos os azulzinhos são service. É que eu não quis ficar escrevendo ride service, fare service pra não ficar mais poluído do que seja, tá? Mas isso aqui são os serviços principais, tá? Só pra vocês só pra deixar claro isso pra todo mundo tá? Só pra deixar cada vez mais claro mesmo tá? Ah, beleza a princípio era isso a princípio era isso, só de bater o olho que eu senti mais falta foi essa questão da definição dos serviços, se ia ser um monolito ou microserviço ou alguma coisa assim e a questão do que eu estou transacionando nessas requisições do que está indo qual é o contrato dela Perfeito tem gente falando aqui muita consistência eventual Outra coisa só que eu senti Falta também Mas aí fugiria um pouquinho Da ideia principal Do que a gente tinha ali Naquele projeto De caso o sistema tem alguma falha De conexão Como que a gente vai saber que de fato Aquela informação ela foi É de caso o sistema tem alguma falha de conexão, né? Como que a gente vai saber que, de fato, aquela informação, ela foi ou não, entendeu? Por mais que a gente tenha um monte de fila, essas filas, elas já vão suportar isso, elas vão armazenar esse tipo de informação, mas era só isso. Show. Galera, eu vou dar uma dica para vocês, tá? Em relação a system design, nesses casos. Toda vez que alguém botar uma fila, você vê, você, por padrão, você vai partir do princípio. Tem resiliência, eu vou ter garantia de entrega e vou ter garantia de recebimento, tá? Como isso vai ser implementado, aí o que pode acontecer? Na pergunta do deep dive que a pessoa vai dar, ela pode chegar e falar, essa fila, se acontecer isso se acontecer aquilo, aí é uma pergunta muito mais exploratória entendeu? Pra entender as minúcias daquele tipo de coisa, tá? Um ponto importante que teve gente que colocou aqui, falou muita consistência eventual, teve gente que colocou, caras qual é o problema de eu trabalhar de forma totalmente assíncrona dessa forma? Eu não vejo problema nenhum, entre aspas nesse caso aqui, de consistência eventual. Porque simplesmente eu estou pegando uma informação, mandando para uma fila, quando eu ler aquela informação, eu vou preencher. Se eu tentar fazer isso totalmente de forma assíncrona, eu não vou conseguir. Jamais um microserviço desse vai conseguir receber um trilhão de requisições, ainda mais uma hora de rush ou qualquer coisa desse tipo. Então, assim, consistência eventual, o maior problema ali não é a consistência eventual. O maior problema que a é a consistência eventual. O maior problema que a gente tem que tomar cuidado é que, nos requisitos funcionais, a gente tem alguns pontos importantes, que é garantir que o motorista não seja oferecido para ele duas corridas, ou que o motorista possa aceitar duas corridas ao mesmo tempo. Esse é o nosso principal ponto de consistência. Agora, fora isso, o que eu quero é disponibilidade no meu sistema, tá? E eu tenho uma regra. Eu posso cancelar uma ride em dois minutos se eu não tiver a confirmação de o meu motorista. Aí eu posso cancelar e tudo que estiver rodando ali na fila, quando terminar de processar eu falo, essa cara já tá cancelado, vou até descartar esse tipo de mensagem agora. Tá? Posso dar um pitaco aí também? Por favor. No desenho, eu acho que ao invés dos serviços, ter que conhecer para onde que ele tem que enviar poderia ter alguns tópicos, onde ele só informa ocorreu tal coisa e quem tiver interessado assina ali, né? Subscreve. Então, poderia pra quando tem algum evento que tem várias filas interessadas ou vários outros serviços interessados, você pode fazer com que a fila se inscreva nesses tópicos. Tá, mas vamos lá. Eu tenho uma pancada de fila. Tá? Como é que você desenha isso Galera, tem alguém Desenhando a minha tela, cara, pelo amor de Deus Ô Leonan, tenta tirar essa permissão, cara Tem um cara botando cheio de verdinho aí na minha tela Vou pegar o exemplo desse Desse ride Eu tô pegando pela cor, porque não necessariamente eu consegui guardar tudo aqui. Mas ele tem duas setas saindo ali. Então, imagino eu que ao acontecer um processamento, ele vai mandar pra essas duas filas, que é o ride request e pro notification. Pela cor, então ele poderia esse processamento que aí a gente pode dar um nome pra ele x aqui, ele pode ter um tópico que x ocorreu ele terminou de processar aquilo e aí a fila de write request você sempre tem location request e aqui você tem o response, você tem uma fila pra request e uma pra Response. Só escuta quem quer o Response e só publica quem processa ou recebe a Request. Então isso tá colocado em cada um dos tópicos. Ou em cada fila, da forma como você estiver colocando. Certo, mas aí não tem, vamos supor, ele tá mandando tem algum processo aí que tá mandando pra duas filas? não ah, ok é porque pela cor da seta parecia que tinha é por isso que eu imaginei que poderia ter um tópico só de mensageria onde ele só informa, ó, acabei de processar tal coisa, e aí se tivesse mais de uma fila ou mais de um serviço que queira e tem intenção de receber aquela informação ele poderia se escrever ali mas no caso pelo visto não é o caso aqui vamos lá galera que eu vou só para só para daqui a pouco eu chamo mais gente para gente discutir Wesley eu vi aí que está faltando uma certa persistência e estou achando que essa API Gateway está com muita responsabilidade. Cara, API Gateway serve exatamente para isso, tá? Isso aí fica sossegado. API Gateway é exatamente para isso, cara. Ela fica na frente de todo mundo mesmo. Sobre persistência, eu não coloquei os bancos de dados ainda, porque a gente vai separar uma parte só para falar de banco de dados. Mas eu vou colocar aqui para vocês os dois pontos que eu vejo mais problemáticos nesse sistema de design. Bom, o primeiro ponto aqui é que, sim, a gente tem que garantir resiliência, garantir que a gente não vai perder informação. Obviamente que em sistemas desse tipo, você vai ter que trabalhar com fila, sim. E normalmente, na prática, no dia a dia ali, provavelmente vai acontecer coisas desse tipo. Ter um tópico de request, um tópico de response, ou coisas desse tipo. Ter um tópico de request, um tópico de response, ou coisas desse tipo. Mas o grande ponto é que quando você vai fazer o system design de algo, já fica evidente que se eu estou publicando algo de uma fila, esse dado vai ser lido e consumido e outro sistema vai pegar essa informação. Então, se eu ficar colocando pra cada fluxo do meu system design, uma fila pra cada pedacinho, acaba deixando a parada extremamente confusa. Tá? Esse aí é o primeiro ponto. Não que o sistema não tenha fila mas o ponto principal que eu quero trazer aqui pra vocês é o seguinte galera o system design ele tem que conseguir quando você bate o olho, trazer clareza do que o sistema está fazendo teve um dos pontos que eu não sei eu não sei quem falou agora mas que não estava claro os dados que estavam tra agora. Mas que não estava claro os dados que estavam trafegando, não estava claro o que estava passando ou o que estava trafegando, alguma coisa desse tipo. E realmente não está claro. O que eu consigo ver aqui é a request inicial e daí eu tenho que controlar a parada com cor. O que acontece na prática é o seguinte, galera. Essa parada aqui é confusa. Quem bate o olho não consegue entender. Você fica que nem um labirinto, olhando, tentando seguir um monte de seta pra parada começar a fazer algum sentido na sua cabeça, tá? E é muito comum a gente encontrar coisas desse tipo, tá? E dependendo do nível de especificidade, uma parte do sistema, você vai ter que fazer coisas parecidas, mas você não vai fazer um sistema inteiro botando todas as filas de todos os sistemas e todos os fluxos dessa forma aqui, esse sistema design é pra ser de alto nível, mas tá uma mistura de alto nível com baixo nível nele ao mesmo tempo tá, e isso aí acaba não conseguindo representar claramente tudo que o sistema tem que fazer porque tem informação demais. A outra coisa clara aqui nesse system design que acaba sendo muito ruim é essa quantidade excessivas de setas e apontamentos tentando mostrar o fluxo de tudo acontecendo a todo tempo. Isso é horrível para um System Design. Ok? Então, quanto menos setas você colocar, é melhor. Mas, você tem que conseguir fazer a representação disso de uma forma que também a pessoa entenda o fluxo sem as setas, ou sem o uso excessivo de setas, de apontamentos tá? Então esse é o ponto a outra ponto aqui, galera, sabe o que que é? é que é muito louco preparar essas aulas e bater esses papos com vocês mas, obviamente, vocês perceberam que eu tive que tirar um tempoco preparar essas aulas e bater esses papos com vocês, mas, obviamente, vocês perceberam que eu tive que tirar um tempo pra montar isso, pra fazer essa aula, e ainda mais pra falar que isso aqui é errado, entre aspas, entendeu? Mas, eu gastei um tempo pra fazer isso. E eu sabia o que eu queria fazer. Tá? Eu sabia onde eu queria chegar, eu sabia onde eu queria chegar e sei lá, eu gastei meia hora pra fazer esse negócio. A minha pergunta aqui é, você numa entrevista de System Design, se alguém fala, copia essa imagem e desenhe isso no Scalidro, só replique isso. Cara, você vai demorar 20 minutos só pra conseguir desenhar esse negócio. Isso porque você não conseguiu pensar. Se você tiver que... Faça um teste. Pega essa imagem, abre o Scaled Draw e tente copiar exatamente como eu fiz. Você vai gastar 20 minutos brincando, tentando olhar certo e replicar. Ou seja, é inviável você conseguir fazer um system design rápido, que as pessoas entendam, nesse caso, em contexto de entrevista, com esse nível de profundidade e confusão, e não somando muito, na realidade, você já falhou na entrevista no meio da história. Seu tempo vai bater e você vai estar ainda escolhendo corzinha que você vai querer fazer nas setas. Tá? Então, isso aí é um ponto importante pra caramba pra vocês levarem em consideração. A regra é, galera, bateu o olho, ficou difícil de entender? Muito difícil de entender? Tem coisa errada. Cheirou mal. Então, essa aí é a verdade da história. Agora, existem outras formas que a gente pode trabalhar? existem e eu vou tentar pegar uma delas agora aqui pra vocês espera só um pouquinho deixa eu pegar aqui, eu tenho que copiar e colar aqui, porque senão não ia eu ia gerar confusão aqui pra vocês e eu espero conseguir copiar e colar aqui, porque senão não ia... Eu ia gerar confusão aqui pra vocês. E eu espero conseguir copiar e colar na realidade. Deixa eu pegar aqui, copiar e colar. Ele tá bem mais fácil e bem menor aqui, eu acho que é mais fácil de entender. E daí na hora que eu pegar aqui, copiar e colar. Ele está bem mais fácil e bem menor aqui, eu acho que é mais fácil de entender. E daí, na hora que eu mostrar isso, a gente já vai falar de banco de dados, daí a gente aproveita tudo numa só, tá bom? E novamente, galera, tá? Eu não estou dizendo que esse System Design é o final e que se eu fizesse uma entrevista para entrar na maior Big Tech ou em qualquer Big Tech, eu não seria criticado ou se não tem pontos ali que muitas pessoas podem não concordar, inclusive vocês, tá? A ideia aqui não é necessariamente eu provar que eu estou certo nesse meu System Design, mas que vocês consigam entender o raciocínio que eu tive na hora de criar esse cara, tá? Então, esse aí é um ponto bem importante que eu queria trazer aqui pra vocês. Eu só quero agora dar um jeito de desselecionar os bancos de dados. Bom, eu vou colocar já os bancos de dados, daí a gente discute em cima desses caras aqui, tá? Deixa eu ver se eu consigo colar aqui. Colei. Bom, bom, eu acho que ficou mais simples de vocês conseguirem ver agora, deixa eu tentar jogar esse cara aqui mais pra baixo e agora galera vocês acham que melhorou pra entender um pouquinho melhor? E agora, galera? Vocês acham que melhorou para entender um pouquinho melhor? Batam um olho aí. Se vocês puderem ignorar, abstrair por hora o banco de dados, eu agradeceria, tá? Só pensem nos serviços por enquanto. Tá? tá? qual que é a principal simplificação e a lógica disso aqui é óbvio que o rider e o driver, eles vão fazer várias requests em diversos momentos, que eles vão receber a notificação, que eles vão enviar a notificação é óbvio que a ride vai receber um monte de chamada o tempo inteiro, tá? é tudo muito óbvio, a Riot vai receber um monte de chamada o tempo inteiro. É tudo muito óbvio. Então, ao invés de eu querer fazer um fluxo pra cada coisa, o que eu posso fazer? Eu posso apontar uma seta, nesse caso, pra uma fila, que eu tô dizendo, cara, se tiver um show da Taylor Swift, se tiver um show do Justin Bieber, sei lá, o show do Paramore, que eu sou fã e todo mundo tiver na saída e todo mundo solicitando uma corrida eu preciso fazer com que esse cara por mais que ele escale e outra coisa, um ponto importante aqui, tá pessoal todos esses caras aqui são diversas instâncias eu não tô falando que é um único serviço. Todos esses caras aqui, eles escalam de forma horizontal, tá? Só pra já deixar claro aqui isso pra vocês, tá? Todos esses caras, eles escalam de forma horizontal de qualquer forma. O ponto aqui é que, quando eu tô falando no serviço de ride, aqui claramente eu posso pensar, que, quando eu estou falando no serviço de ride, aqui claramente eu posso pensar, olha, quando eu caio aqui, eu vou poder fazer uma estimativa de quanto que vai custar, eu posso selecionar para criar uma nova corrida, e eu posso aceitar ou não uma corrida. E isso aqui para mim vai cair numa corrida. E o que eu estou dizendo aqui nessa fila, no final das contas, é que esse microserviçoa, no final das contas, é que esse microserviço aqui, no final das contas, ele, por mais que ele esteja entopetado de coisas, ele não vai cair porque ele vai ler conforme o consumo. Ah, Wesley, você quer dizer que esse microserviço aqui do Ride para Matching não precisa de uma fila? Não estou dizendo isso. Talvez até precise, dependendo do contexto. Tá? Mas o que eu tô mais apontando aqui com as filas são quais são locais que claramente são críticos onde eu vou receber a todo momento booms de requisições que o meu sistema pode cair. Tem dois caras muito claros. Na hora que eu vou pedir corridas, umoms de requisições que o meu sistema pode cair. Tem dois caras muito claros. Na hora que eu vou pedir corridas, um monte de gente pedindo ao mesmo tempo, e provavelmente a localização dos caras. Todo momento eu vou receber isso. Então esses pontos são gargalos claros do meu sistema. A verificar o match das coisas, pode ser gargalo? Pode. O fair pode ser gargalo? notificação pode ser gargalo, tudo pode. Tudo isso aqui, em algum momento, pode trabalhar com fila. E talvez trabalhe, inclusive. Em muitos casos, deva trabalhar. Mas existem situações muito claras onde você pode especificar para apontar e dizer, cara, esse ponto aqui é um gargalo e eu já estou deixando claro aqui para você que eu vou precisar de algo, no meio do caminho, pra eu conseguir dar conta dessas requisições, tá? Então, esse aí é um ponto importante aqui pra vocês conseguirem se ligar. Tá? Então, esse é um ponto importante. Outra coisa aqui, né? Quando eu tenho uma nova corrida, eu tenho que pedir, né? Pra fazer o matching, pra ver quem são os motoristas que estão próximos pra eu fazer o match do motorista com o driver aqui pra mim, né? Então, esse serviço de ride vai fazer o match a todo tempo nesse cara aqui. Da mesma forma que o ride, ele vai querer pegar o valor de quanto que vai ficar a corrida o tempo inteiro. O que eu posso fazer aqui nesses tipos de coisa? Eu posso, por exemplo, caso eu queira demonstrar, sei lá, pro entrevistador naquele momento, o seguinte, olha, esse tipo de comunicação desse cara chamando aqui porque eu preciso pegar um valor rapidamente, eu vou fazer de forma assíncrona, utilizando o GRPC. Nesse momento aqui, eu vou fazer de forma assíncrona, utilizando o gRPC. Nesse momento aqui, eu já estou apontando para quem está me entrevistando que eu não estou apenas pensando no REST. Então, pode ser encarado com uma pequena, como se diz, provocação, ou mostrar que você tem conhecimento de outros tipos de protocolo, tá? Então, isso aí é um ponto importante aí pra vocês, beleza? Uma outra coisa clara aqui também é toda vez que vai acontecer uma nova ride, né? Ou seja, eu vou notificar, né? Ah, teve uma aceitação, não teve uma aceitação do cara e etc, eu vou mandar uma notificação cara, qual notificação? aonde fica? eu estou apenas colocando que eu tenho um serviço de notificação aqui qual vai ser o serviço? aí a gente pode entrar naquele deep dive, a gente vai entrar naquele deep dive. A gente vai e vai explorar. Poxa, aqui eu poderia fazer uma notificação usando o Firebase. Aqui eu poderia usar uma notificação usando tal serviço da AWS. Aqui eu poderia usar uma notificação usando o Redis. Poderia ser um monte de situação. Acho que o principal ponto aqui é a pessoa bater o olho e entender um pouco mais o que faz o sistema. Eu posso pedir uma ride, eu posso fazer o request, eu posso aceitar ou não. Eu tenho o matching dessa ride, eu posso fazer o cálculo de preço, e eu fico atualizando a localização desses caras o tempo todo. Cara, se você perceber, praticamente todos aqueles endpoints que a gente cobriu estão cobertos somente com esses caras que estão, de forma geral, até que simples de entender. Está fazendo sentido o que eu estou falando para vocês, galera? Não estou dizendo, inclusive, que é o melhor system design que existe do Uber, tá? Muito longe disso. O que eu tô querendo passar aqui pra vocês é a ideia do raciocínio da construção do negócio. Tá? Vai ter muita diferença de mostrar isso pra isso. E isso, você demora poucos minutos pra fazer, e você faz isso conversando com a pessoa. Na real, eu não consigo fazer isso conversando com alguém. Eu não consigo ficar enfiando esse monte de seta aqui, cara. É muito complexo pra eu fazer. Dessa forma, eu consigo ver os meus serviços, consigo ver quem que te comunica com quem, vejo quais as operações que esses principais caras fazem e ponto. Então, aí tem um ponto importante aí pra gente conseguir trabalhar. Legal? Agora, tem uma coisa interessante aqui pra vocês conseguirem se ligar, tá? Que é o seguinte, banco de dados. Normalmente, a se ligar, tá? Que é o seguinte, banco de dados, normalmente, quando você vai trabalhar no System Design, você vai apontar os principais bancos de dados que vão gerar determinadas discussões. O que eu estou querendo dizer? Você acha que esse microserviço que faz cálculo de discussões. O que eu estou querendo dizer? Você acha que esse micro serviço que faz cálculo de corridas tem um banco de dados? Cara, com certeza tem um banco de dados. Serviço que trabalha com notificação, de alguma forma esse cara tem um banco de dados. Normalmente todo micro serviço, de alguma forma ele vai ter um banco de dados. Normalmente, todo microserviço, de alguma forma, ele vai ter um banco de dados. Eu vou querer colocar todos os bancos de dados, de todos os microserviços, de tudo que eu estou fazendo no meu system design? Eu não vou querer fazer isso. Só para eu ficar fazendo isso, eu já vou gastar meia hora também, que eu não tenho, na hora de fazer qualquer tipo de system design. Nesse caso, quais são os caras que eu estou colocando especificamente aqui, que normalmente vai valer a pena a discussão na hora de você trazer qualquer coisa pra mesa ou num contexto de uma entrevista. Primeiro ponto aqui é provavelmente a gente tem um banco de dados, entre aspas, principal, que tenha mais a ver com o domínio principal do negócio, que são as corridas. Então, provavelmente, eu vou ter a corrida, que é o ID dela, vou ter quem que é o motorista, eu vou até aumentar um pouco o zoom aqui, para vocês conseguirem ver melhor, mas eu coloquei apenas alguns caras aqui. Eu posso ter o ID, o ID do driver, o ID do rider o ID da fair, né? do fair ID, que é o valor desse orçamento, ou posso ter diretamente aqui o valor de quanto ficou essa corrida, eu posso ter aqui aonde que é o pickup da onde pra onde vai a corrida, o status se ela está em andamento, o status se essa corrida está aguardando confirmação do driver, se está aguardando pode ter diversos status. Eu recomendo, inclusive, dependendo da situação do system design, que você possa colocar coisas do tipo a waiting for driver confirmation. Confirmed for driver confirmation confirmed ongoing não interessa, mas você pode colocar alguns status pra mostrar o seu conhecimento naquele tipo de raciocínio que você tá trabalhando tá, então isso é uma forma de você colocar, uma outra coisa aqui importante é, apesar desse banco de dados aqui, eu não estou dizendo necessariamente se esse banco de dados é relacional ou não. Pode alguém perguntar, Wesley, é relacional ou não é relacional? Cara, por padrão, olhando dessa forma, para mim, um banco de dados relacional seria mais do que o suficiente pra trabalhar nesse tipo de coisa. Porém, dependendo da situação, de algum tipo de recurso, talvez esse banco de dados pudesse ser não relacional, mas com alguns outros tipos de recurso que a gente pode explorar aqui depois, tá? Agora, aqui a gente começa a entrar numa questão um pouco mais complexa porque é o seguinte se tem uma coisa que a gente tem que conseguir processar bem num Uber provavelmente é a localização de todo mundo quando eu falo eu quero uma corrida, eu tenho que conseguir consultar rapidamente quem são os motoristas que estão em volta daquela região, pra eu conseguir ter os IDs daqueles drivers pra eu poder oferecer aquela corrida daquela pessoa pra aquele driver, certo? e quais nesse caso aqui seriam opções tá? de bancos de dados pra eu trabalhar com esse tipo de coisa. Alguém consegue trazer aí pra mim algumas opções? Tem gente falando várias opções aí, caras. Vamos lá. Vamos lá. Eu vou pegar dois que estão aparecendo bastante, tá? E vou trabalhar. O Postgres apareceu bastante aqui, né? Com o PostGIS, né? Que é para a parte de localização ali do Postgres. Vocês sabem como é que o Post... o PostGIS funciona? Tá? É aí que é importante, tá? Se você tá numa entrevista e você fala isso, a pessoa vai perguntar, ok, mas por que que você tá usando o PostGIS? Alguém que escolheu esse banco de dados e escreveu aí para a gente no chat, quer falar por que escolheria esse banco de dados? Alguém poderia falar e ligar o microfone? Não? Então, beleza. Seguinte. Não, então beleza Seguinte Seguinte, galera Se você tá usando o Postgres Basicamente o que ele vai fazer Esse cara, ele vai pegar Um monte de posição de geolocalização Que é o que ele faz, certo? E vai tá espalhado Essa parada pra tudo quanto é lugar, a geolocalização e tudo mais. Aí, o que normalmente esse cara vai fazer? Ele vai separar alguns quadrantes e daí se ele acha que e se eu falar aqui que eu estou querendo pegar três motoristas por quadrante, normalmente a gente coloca uma variável K aqui, tá? O que acontece aqui nessa tá? O que que acontece aqui nessa história? Ele vai subdividindo esses caras aqui, até conseguir gerar esses pedaços, daí recursivamente ele para. Basicamente, ele trabalha como se fosse de uma árvore binária em quadrantes. Por que que esse cara aqui em tese funcionaria, mas ao mesmo tempo não funcionaria? Pra esse cara conseguir fazer isso, ele fez toda uma indexação pra trabalhar dessa forma. Concordam comigo? Agora, tem motorista entrando e saindo toda hora, mudando a localização toda hora, ficando offline, entrando, saindo. Se você tem essa entrada o tempo inteiro, dinamicamente, ainda mais quando tem o show da Lady Gaga lá e etc, o que que vai acontecer? Esse índice, ele vai ter que ser recalculado o tempo inteiro, toda hora. E ferrou. Agora, o bom de tudo isso é que quem pensou nessa extensão do Postgres já se ligou que o tipo de banco de dados que a gente precisava nesse caso seria algo que tivesse uma especificidade muito melhor para a parte de geolocalização, o que é muito bom. Então, isso aí é um ponto importante para a gente se ligar. É uma solução ok? É, mas eu acho que não funcionaria bem no caso do Uber. Mas se você trabalha com algum serviço desse tipo e usa o post de SI, por favor me fale, porque essa reindexação o tempo inteiro faz mal, de forma geral. Agora, se você vai fazer, vamos imaginar o seguinte, o mapeamento de diversos, sei lá, estabelecimentos, diversas fábricas, diversos lugares, no mundo inteiro, e você precisa fazer esses cálculos, mas esse índice não fica atualizando de uma forma tão dinâmica, com certeza é uma opção que você pode usar e que vai funcionar super bem aí também. Então, tudo tem seu caso de uso. Então, agora, essa mudança de índice o tempo inteiro, no caso do Postgres aí, talvez ele fosse um problema aí nesse caso. Fechou? Agora, agora, tudo que tem muito dado e que faz índice ser recalculado o tempo inteiro, cara, normalmente essa parada não vai funcionar muito bem. Tá? No caso, tá? Ainda mais falando em persistência de dados e a gente tá falando em disco com essa parada tão dinâmica, talvez a coisa fique um pouco mais complexa agora se eu conseguisse fazer essa parada rodar em memória certo e ainda tivesse um e fazer essa parada, rodar em memória. Certo? E ainda tivesse um mecanismo eficiente de fazer esses tipos de busca. Baseado nessas localizações e coisas desse tipo. Seria algo muito bom nesse caso, tá? Eu vou trazer uma opção aqui, que nesse caso é o Redis, e o Redis ele tem uma parada que é chamada de GeoHashing. A ideia dele é um pouco parecida de como que o Postgres trabalha, tá? Basicamente, o que ele faz é, ele pega um quadrante gigante também, ele começa a splitar esses caras aqui. Aí, dentro desse cara aqui, sei lá, eu tenho aqui o número 1, ele pode criar aqui embaixo um outro quadrante, que é o 10. E dentro desse 10, ele pode criar um outro quadrante aqui que é o 100 e todos esses caras que estão aqui dentro eles acabam tendo o que? um hash único então conforme o tamanho do hash que você vai ter em relação a algo você tem o maior número de precisão aonde aquilo está dentro desses níveis de quadrante. Então, se eu vou buscar um hash pelos quatro primeiros caracteres, eu tenho que essa ideia está até dentro desse quadrante 10 que está dentro do 1. Agora, se eu for buscar oito caracteres, eu sei que o cara ainda está dentro do 10, dentro do quadrante 100. Então, quanto maior é o número do hash que eu tenho, mais preciso é onde está a localização daquilo que eu estou buscando. E a grande sacada disso é que cada motorista ou cada pessoa onde está, ela está simplesmente armazenada num hash. E esse hash acaba facilitando a vida aí pra gente. Então, essa talvez seja uma forma de você trabalhar. Não estou dizendo que é a única, e também não sou especialista em geolocalização. Mas, essa pode ser uma boa pedida. Uma outra pedida é que o banco de dados ele é em memória. E se esse cara ser em memória, o que vai acontecer? As minhas consultas acabam conseguindo ser cada vez mais rápidas também. Agora, uma coisa a gente não pode deixar de colocar. Eu posso usar esse banco de dados em memória de localização porque eu tenho que ficar fazendo matching de motorista, fazendo esses tipos de coisa o tempo inteiro. Mas, obviamente, que eu posso também pegar esses dados de localização e gravar em outro tipo de banco de dados para eu ter dados históricos, para eu conseguir fazer processamentos, fazer estudo, fazer o que for preciso, e depois eu posso gravar, juntar esses dados, botar em parquet, botar dentro de um S3 para armazenar e deixar ali num storage cada vez mais cold, tá? Mas essa base aqui em memória é uma base quente do que tá acontecendo aqui nesse momento, tá? Então, você consegue uma velocidade muito grande de consulta, né? E você consegue pegar essas informações de uma forma muito rápida. Então, o location consegue gravar e o meu ride matching, dependendo da situação, consegue buscar diretamente na memória, tendo esse tipo de coisa, mas a gente tem um problema aqui na nossa aplicação, tá que é o seguinte lembra que tem aquela parada de um motorista não poder aceitar duas corridas ao mesmo tempo? Como que a gente consegue fazer isso? Vamos imaginar que a gente acabou de sair do show do Elevation Worship, que eu vou no show deles esse ano, e daí, o que que acontece? A gente, ali no show, um monte de gente lá pedindo Uber e a gente tem ali alguns motoristas ali na área. Como é que eu vou mandar a solicitação pra aquele motorista? Bom, eu tenho uma lista de motorista, provavelmente eu vou fazer algum loop e vou falar, olha, pra eu não oferecer dois motoristas pro Wesley, eu vou mandar algum loop e vou falar, olha, para eu não oferecer dois motoristas para o Wesley, eu vou mandar para um motorista, se esse cara não aceitar, eu mando para o próximo, mando para o próximo, mando para o próximo. Então, o problema de Wesley ter mais de um motorista nesse ponto está resolvido, porque basta oferecer um de cada vez. Correto? Então, é uma solução bem simples, eu ofereço um de cada vez. Correto? Então, é uma solução bem simples. Eu ofereço um de cada vez e o que pegar primeiro pegou e daí eu não ofereço mais pra ninguém. Então, Wesley ter dois motoristas, esse problema de concorrência é muito fácil de ser resolvido. Agora, o problema aí nesse caso é que tem o Wesley pedindo uma solicitação, mas tem também o nosso amigo de óculos, que é o Bruno Nogueira. O Bruno acabou de sair do show lá comigo e vai para um lugar diferente e fez o pedido junto comigo. E a questão é, como que eu garanto para o sistema para que a solicitação do Wesley e a do Bruno não vá simultaneamente para o mesmo motorista. E aí a gente entra num problema de concorrência. Esse é o grande problema que qualquer tipo de sistema acaba encontrando em todo momento. Problemas de concorrência. Transações acontecendo de forma praticamente simultânea. Ou, enquanto uma está sendo processada, o que pode acontecer? A outra ainda estava no meio do caminho e daí, como não estava persistido ainda no banco de dados, a gente tem a impressão que aquele driver, por exemplo, estava disponível para os dois naquele momento. Então, esse aí é o maior desafio, vamos dizer, que a gente acaba tendo em qualquer tipo de sistema, desde um sistema de, Cara, sei lá, de comprar ticket de cinema, ou você fazer inscrição numa corrida, que nem eu fiz da Disney, que só cabe 100 pessoas, ou um show onde você vai fazer inscrição. Como que eu não vou vender o mesmo produto para duas pessoas que só tem um no estoque? Tudo isso aí é um problema de concorrência. E tem gente falando que está fora do escopo. Não está fora do escopo, meu amigo. Nos requisitos não funcionais estão aqui, para garantir consistência, o sistema deve evitar que o motorista aceite mais de uma corrida, tá? Então, o que que acontece? Como que a gente resolve problemas de consistência nesse caso? Cara, quando você tem diversos, e lembrando, né, esse ride matching, são vários microserviços dele, tá? Aqui tem um cara, mas são vários microserviços dele, tá? Aqui tem um cara, mas são vários caras desse. Aqui tem esse ponto também que é importante. Esse cara escala horizontal. Então, são vários sistemas desses iguais, replicados, executando a mesma tarefa. Isso aí é um ponto importante a gente saber. Então, como que a gente pode tentar resolver esse tipo de coisa? Trabalhar com o sistema de lock. Tá? O lock, o que que vai acontecer? O lock, ele simplesmente vai falar que aquele motorista ele está indisponível para aquele tipo de transação e você vai fazer isso de forma atômica ou seja, na hora que você tiver um motorista e esse cara tiver o status dele ali eu vou falar que ele está awaiting a corrida tal então essa é a ideia criar uma máquina de estado em relação a corrida e o motorista em relação a ride, que teria o ID do motorista não, na realidade não é em relação a ride, em relação ao driver porque na hora que eu vou fazer o ride matching, eu vou buscar todo mundo que o status não está aguardando confirmação. Ou seja, vou pegar somente os motoristas disponíveis. Mas como que eu sei quem são esses motoristas disponíveis naquele momento? Eu tenho esse cara armazenado em algum lugar e eu vou colocar um lock dele aqui. Tá? Melhor que uma das formas... É uma espécie de um semáforo, certo? É uma espécie de um semáforo, mas isso é um lock distribuído, porque ele vai estar disponível para diversos sistemas ao mesmo tempo. Ou seja, ele vai dar um lock, depois ele vai dar um unlock, caso ele precise. Mas a gente tem mais um outro problema aqui. Eu vou deixar esse cara aqui também em memória. Por que tem mais um outro problema aqui. Eu vou deixar esse cara aqui também em memória. Tá? Por que eu posso deixar esse cara aqui em memória? É rápido para consultar e esse cara vai mudar toda hora. Então, não preciso ficar gastando tempo em disco aqui para mim também. Mas a gente tem um outro problema aqui nesse caso, que é, se o motorista não aceita a corrida e o status dele está mudado, o que acontece? Ele vai ficar indisponível para todo mundo. Tá? Vocês concordam comigo? Esse aí é o grande ponto. E se eu acabo caindo exatamente nesse ponto é como que eu deixo então esse cara disponível depois de um tempo? Tá? Teve um camarada aí, ó, teve gente que escreveu cash, teve gente que escreveu TTL, teve gente que colocou job. Legal. Vamos começar com job. Teve uma solicitação, a gente falou assim, TTL ou eventos. Vamos lá. Job, eu poderia fazer um job realmente. Eu crio um job que a cada sei lá, 30 segundos eu visito esse cara aqui e limpo os caras que estão inscritos há mais de tanto tempo e daí esses caras ficam disponíveis mas significa que a cada 30 segundos eu vou ter um monte de cara preso até esse job meu rodar e aí eu tenho uma um monte de cara preso até esse job meu rodar. E aí eu tenho uma regra de negócio. Eu posso fazer o seguinte, olha, eu mando uma solicitação. Se aquele motorista não aceitar em 10 segundos, eu vou para o próximo motorista. E eu vou para o próximo motorista. Se eu rodo esse job a cada 30 segundos, vai ter motoristas que vai ficar 20 segundos ocupados enquanto esse job não rodar. Vocês concordam comigo, né? Mas, se eu rodar esse job a cada 5 segundos também, eu também vou ficar detonando as coisas à toa. Ok? Então, a solução que deram ali de TTL, né? Que é Time to Leave, é uma ótima solução. Tá? O que que eu faço? Eu falo que esse cara aqui tem um TTL, sei lá, de 10 segundos. O que que isso significa? Uma vez que esse cara entrou aqui e ficou 10 segundos aqui dentro, sem mudar esse status, ou ficou 10 segundos aqui de qualquer forma, eu removo ele daqui. E daí esse motorista, ele vai ficar disponível novamente pra mim. Então o cara entrou, o tempo máximo que ele pode ficar nessa tabela é de 10 segundos. Passou 10 segundos, esse registro é removido e eu não vou ter mais esse tipo de problema de lock. Então, uma das coisas que a gente tem que se ligar, galera, é que trabalhar com lock nos dias de hoje é algo complexo, é algo que pode fazer seu banco de dados ficar em modo de contenção o tempo inteiro, principalmente quando você dá um select for update e tem que realizar um monte de transação no meio até dar o commit no final. A gente tem locks chamados lock otimista, lock pessimista, que você fica retentando, garantindo a versão, para garantir que você está falando da mesma versão até dar o próximo commit, senão você refaz a tentativa, mas nesse caso aqui, cara, simplesmente botar um TTL aqui no registro, já vai resolver. Cara, quem pode, quem aceita TTL em memória? Redis. Pode ser uma ótima opção aqui também, parece que a gente está usando Redis pra tudo, mas ele faz isso muito bem. É um banco de dados em memória, é super rápido, ele tem TTL e ele resolve aqui a minha vida. Ou qualquer banco de dados que consiga fazer coisas parecidas. Por exemplo, dependendo da situação, eu posso até pegar outras informações de RAID e colocar num Dynamo, por exemplo. Daí vai depender muito. Mas o Redis aqui, ele pode funcionar de uma forma aqui super tranquila, super de boas, e que vai, de forma geral, resolver esse meu problema de lock. Então, se vocês olharem, galera, em relação a esse System Design, está de longe de ser qualquer system design melhor desse mundo e, honestamente, eu não sei o quanto esse system design seria refletido numa entrevista de uma Big Tech se eu estivesse fazendo, tá? Mas, de forma geral, ele cumpre o que a gente acabou colocando. A grande questão aqui é as perguntas exploratórias que as pessoas vão trazer. E eu vou passar aqui para vocês como tarefa de casa hoje, tá? Porque amanhã a gente tem mais uma aula e a gente não vai terminar tão tarde hoje quanto da outra vez, tá? E a nossa lição de casa aqui vai ser o seguinte, anotem, tá? Claramente. Imagine que nós estamos falando de grandes cidades, como São Paulo. Legal? São Paulo é uma cidade gigante tem gente pra caramba e aí a gente também tem cidades que tem menos pessoas pira porra do bom Jesus aonde que eu nasci, é uma cidade de 15 mil habitantes que tem Uber lá mas não tem semáforo, pra vocês terem uma ideia ok então então o que que acontece é o seguinte. Como que você conseguiria equilibrar esses tipos de coisa baseado na região que a pessoa está? Eu vou dar um exemplo. Se eu estou em São Paulo, todas as solicitações de São Paulo vão bater aqui. Se eu estou em Pirapora, as solicitações de Pirapora vão bater aqui. Se eu estou no Rio de Janeiro, elas vão bater aqui. A gente está, basicamente, trabalhando com esses serviços específicos aqui, atendendo tudo quanto é cidade, atendendo tudo quanto é metrópole, atendendo tudo quanto é país. Como que a gente poderia fazer, de forma geral, uma separação mais inteligente para que o processamento da minha aplicação onde eu tenho uma alta quantidade de requisições em um lugar acabe não afetando o processamento de requisições onde tem poucas pessoas. Por exemplo, deveria ser muito mais rápido fazer um processamento desse em Pirapora, que tem 15 mil habitantes e pouco Uber. Agora, se eu cair na mesma fila ou no mesmo processamento de São Paulo, Pirapora pode demorar para processar igual São Paulo, porque a gente está usando exatamente as mesmas condições. Fez sentido o que eu estou dizendo? Então, eu queria que vocês pensassem nesses tipos de solução. Pode ser na criação de outras filas, pode ser a criação de outros serviços, pode ser a utilização de Edge Computing, a forma como vocês acharem melhor. Inclusive o banco de dados, por exemplo. Tá? Maravilha? Então, esse aí é um dos pontos que eu queria trabalhar aqui com vocês em relação ao que a gente vai trazer. Também, a gente vai, amanhã, ver algumas coisas muito importantes. Quando a gente olha esse System Design, quando a gente olha a quantidade de locais que tudo isso tem que rodar, entre aspas, no mundo inteiro, e como que a gente consegue entregar, fazer deploy de todas essas coisas de uma forma consistente ao longo de diversos lugares e que a gente consiga manter equipes de desenvolvimento organizadas, tá? Então, isso aí é um ponto, assim, importante pra vocês aí levarem em consideração, tá? Agora, tem uma coisa importante também que eu quero trazer aqui para vocês, pessoal. Se vocês puderem, tentem criar um system design alternativo desse do meu, tá? Eu olhando o meu aqui, eu já vejo 10 milhões de coisas que eu mudaria se eu fosse criar uma nova versão pra ele ficar mais fácil de entender ou ainda mais expressivo tá? Então eu queria que vocês sentassem e fizessem uma crítica em relação a isso uma coisa pra mim que é claro, tá? É que qualquer system design que for baseado em aplicativos tipo Uber, eu não vejo esses caras sendo tão diferentes do que a gente tá colocando, honestamente falando, tá? Eu acho que se você pegar cinco staff engineers e passar esse mesmo problema, eu acho que esses caras, eles vão fazer coisas parecidas com isso, não necessariamente iguais. Mas eu acho que vai ter um location service, vai ter um fair service, ou vai ter um ride matching, ou o que pode acontecer é não ter um ride matching e ter um único cara que só vai tratar ride pra tudo, pra simplificar ainda mais o system design e não ficar enchendo de serviço talvez não tenha um serviço de notificação ou ele coloque só um serviço gerenciado então pode ter alguém que coloque um web firewall tem gente que pode tirar um API gateway pode ter gente que pode colocar micro API gateways aqui na frente de cada serviço pra proteger esse contexto. Tem um monte de opção aqui que dá pra utilizar. Um monte de variação. Mas eu acho que qualquer system design que você vai olhar em relação a Uber, e que provavelmente vocês vão fazer acabam sendo um pouco parecidos com esse, inclusive os system designs que foram mostrados ontem, apesar da forma como eles estavam apresentados se você olhar de forma fria, é muito parecido com isso também que foi apresentado, quem estava aqui ontem eu acho que pode concordar comigo tá, mas eu acho que o grande ponto, de uma forma ou de outra, é a gente conseguir entender, tá? O quão complexo você pode fazer algo de algo que pode ser muito mais simples de ser representado. Tá? Eu acho que essa aqui que é a grande sacada. Agora, pessoal, uma outra coisa que eu não posso deixar de falar, tá? Pessoal, escaneiem esse QR Code. Esse QR Code é uma solicitação de contato pra que a gente consiga bater um papo com você pra falar sobre o MBA em arquitetura full cycle que a gente tem, tá? A gente já teve ontem várias pessoas que preencheram o form, a gente entrou em contato, muitas dessas pessoas já viraram alunos e se você é uma delas, cara, seja muito bem-vindo aí, tá? Se você caiu aqui e não sabe, tá, o que é o nosso MBA, o grande foco dele tá em te ajudar a ser capaz de liderar, a desenvolver grandes soluções em grandes empresas. Basicamente, o que a gente tá vendo aqui e da forma como a gente está trabalhando aqui nesses dias representa muito como que são as aulas do MBA. Como é que funciona o MBA ali por dentro, de forma geral? Você tem as aulas que são disponibilizadas... Deixa eu ver se eu consigo trazer aqui para vocês. Deixa eu ver se eu tenho o MBA nessa conta que eu tenho aqui basicamente você tem os módulos de cada aula ou seja, de cada matéria que você vai fazer, essas matérias elas tem avaliações mas ao mesmo tempo que essas matérias elas tem as suas avaliações, que são coisas bem simples na realidade, a nossa ideia não é ficar fazendo você fazer provinha, mas o ponto principal aqui é, você tem acesso a essas diversas disciplinas, cada disciplina tem professores diferentes, que são especializados naquele tipo de assunto, tá? E semanalmente, a gente tem dinâmicas como essa que você tá tendo aqui no Zoom com a gente. Então, tem esse nível de proximidade, então tem momentos que você tem convidados que participam e dão as talks aqui pra gente, tem diversas participações especiais, se você entrar na página do MB você consegue ver e a gente sempre tá tentando trazer e agendar com novas pessoas uma outra coisa importante a gente tem essas sessões dinâmicas de breakout room que a gente fez ontem, tá? onde a gente separa as pessoas, as pessoas obviamente com mais tempo, mas as pessoas conseguem fazer networking, conseguem trabalhar em grupo, conseguem fazer entregas e etc. A gente tem sessões de mentoria, tá? E a gente tem laboratórios, tá? Inclusive essa semana vai ser lançado um laboratório, na realidade, inclusive de system design pra galera. Ou seja, a gente traz o problema, a pessoa tem tanto tempo pra resolver, normalmente a gente dá 15 dias e depois a gente faz uma aula ao vivo, explicando como que é aquela solução e fica disponível ali também pros alunos. Então, o que eu poderia dizer aqui pra vocês, galera, é que a dinâmica do MBA nosso, aqui da Full Cycle, ela é bem similar à dinâmica que a gente está tendo aqui. Vocês acessam as aulas na nossa plataforma, a gente tem as sessões com convidados, a gente tem as sessões com breakout room, a gente tem sessões que vão ser de mentoria e a gente tem laboratórios. Então a ideia não é fazer apenas você assistir vídeos com as pessoas famosas, mas a ideia é que você também tenha esse contato mais próximo. E esse contato mais próximo, ele não é necessariamente apenas comigo, tá? Que eu estou longe de ser o cara. Tem caras aqui muito tops, né? Poxa, se você... Cara, deixa eu pegar aqui um tops, né, poxa se você cara, deixa eu pegar aqui um exemplo arquitetura hexagonal se você cair nas aulas de arquitetura hexagonal quem tá dando aula aqui nessa parte é o Swack, que é expert né, ele é o tech lead dos tech leads no mercado livre mas ao mesmo tempo a gente tem uma aula aqui de 40 e poucos minutos que foi especificamente do Alistair Coburn contando a história de como ele criou a arquitetura hexagonal, de como que foi, a gente fez entrevista com ele, a gente legendou tudo e colocou isso ali pra eles, tá? Então eu acho que isso são coisas que, entre aspas, enriquece muito. Uma das coisas que a gente sempre quis trazer aqui no MBA é, não é só ensinar a tecnologia. Seria muito legal se a gente trouxesse quem criou aquela parada pra dar aula. Então, quando a gente vai falar de Solid e Design Patterns, adivinha com quem a gente tem introdução das aulas de Solid? Com esse cara aqui, ó. Deixa ali. É que a minha DRM tá bloqueando aqui. Mas a gente tem aula com o Uncle Bob passando por todos os princípios. Aqui, ó. E tá tudo legendado bonitinho também, pra quem não sabe inglês. Aí, quer falar sobre design patterns? Aí aula design patterns com o Rodrigo Branas, entendeu? Depois disso, né, só patterns comigo de enterprise, application, architecture e também os códigos fontes e etc. A gente também está fazendo algumas coisas muito bacanas e a gente está começando a colocar agora e a gente está fazendo isso para todos os capítulos, caras, e está dando um trampo danado, tá? Que é o seguinte, resumos dos capítulos. A gente está pegando todas as aulas e tem aulas. E tem aulas, galera, que não faz sentido ler a transcrição. Imagina que eu estou falando um monte de código-fonte para vocês. Faz sentido você ficar lendo transcrição de e clique na variável x? Cara, não faz sentido nenhum. Então, a gente está ali de uma forma extremamente pesada, trabalhando para que todos os capítulos a gente consiga gerar um material adicional baseado em todos os exemplos, inclusive com os códigos dos exemplos que foram dados nas aulas com os professores. Então, tudo que está aqui no resumo do capítulo, por exemplo, aqui, falando de Simple Factory, do Design Pattern, Adapter, Padrões Arquiteturais, Strategy, todos esses exemplos que vocês estão vendo aqui, são da aula do Branas. Mas, aqui não é uma apostilinha. Esse aqui, na real, é o código que o Branas usou na ideia dele então é como que se você lesse esse capítulo, esse resumo é como se você tivesse assistido todas as aulas do Branas naquele momento exatamente com os próprios códigos que ele utilizou então a gente gerou os textos mas a gente conseguiu pegar todo o código ffonte e conseguir colocar dentro de tudo isso. Ou seja, a nossa ideia, no final das contas, é conseguir gerar um livro de cada um desses caras de uma forma, assim, muito forte. Então, assim, a gente está tendo esse ano agora, pra gente, de 2025, um ano bem forte em melhoria dos nossos produtos, galera e a melhoria principal tá em conseguir criar diversas formas de você conseguir consumir o nosso produto uma, assistindo os vídeos, outra participando de sessões como essa no Zoom outra com essas leituras, mas não é simplesmente uma leitura ou um resuminho de IA, mas sim pegando realmente cada coisa que foi falada, linkando com todo o código fonte que tudo foi feito pra conseguir trabalhar pra vocês. Então, a gente tá focando bem forte e a grande sacada é, se você quer aprender arquitetura de solução, arquitetura de software, DevOps SRE, e desenvolver diversas soft skills pra você liderar, trabalhar com diversos projetos, com diversas pessoas, assumir cargos aí cada vez mais de liderança, caras, assim, eu sei que eu sou suspeito pra falar, mas vale a pena você pelo menos bater um papo com a galera nossa. Eu também atendo bastante aluno que tem dúvidas se deve contratar ou não, porque a gente, na real, entende o seu momento profissional pra ver se, inclusive, o MBA faz sentido pra você. Às vezes não faz. Às vezes o momento da sua carreira tá em investir em aprender mais uma linguagem. Às vezes, o momento da sua carreira está em investir em aprender mais uma linguagem. Às vezes, o momento da sua carreira está em fazer um MBA como esse, tá? Então, galera, se você tem essa dúvida, quer saber mais, sem compromisso algum, tá? Escaneia agora esse QR Code. Eu vou pedir também para o Leonan colar aí no chat, tá? Deixa eu ver se eu tenho o link fácil aqui também. O link, para quem não quiser escanear o código-fonte, deixa eu colar aqui, ó. Colar o código-fonte... Colar o código-fonte, não, colar o link, ó, no chat, para quem não quiser escanear o link no chat, pra quem não quiser escanear o QR Code você vai clicar, provavelmente você vai preencher o seu nome e seu e-mail tá? Aí a gente vai entrar em contato com você, a gente vai entender você. A última coisa que a gente quer, na realidade é fazer você entrar num curso que não faz sentido no momento profissional que você tá, tá? Então, esse é o grande ponto aí, galera. Um outro ponto importante também aí nesse caso, é também citar que até essa semana a gente tá em momento de pré-matrícula, tá? O que que isso significa? O valor de pré-matrícula, tá? O que que isso significa? O valor de pré-matrícula galera, parem de rabiscar na minha tela, pelo amor de Deus, João Dias, que vergonha cara a gente tá em pré-matrícula, semana que vem a gente abre as matrículas oficiais e o valor vai ser mais alto, tá? Então eu acho uma boa vocês entrarem em contato e conseguir ter esse desconto de pré-matrícula agora. Fechou? Maravilha, galera? Então, pessoal, mandem ver, tá? O MBA da nossa faculdade, a Full Cycle, ela tem uma faculdade, chama Faculdade Full Cycle de Tecnologia, o FCTec. O MBA é totalmente regulado pelo Ministério da Educação, aprovado no Ministério da Educação, aprovado no Ministério da Educação, tudo certinho, então você recebe realmente um diploma de MBA e tudo certinho aí pra vocês, tá? Então, galera, cliquem no link, preencha aí, provavelmente, a nome e e-mail que você vai ter ali no formulário, a gente entra em contato, entende o seu momento profissional, se fizer sentido, vocês entram com a gente, aproveito para fazer isso essa semana, porque semana que vem, a gente entra com o valor, cheio do curso, tá? E daí, é o que é. Então, aproveite aí para vocês. Beleza, galera? Maravilha, galera? Então, pessoal, boa noite aí pra vocês. Vamos rodar a pesquisa? Ah, claro. E por último, e não menos importante, o Leonan está colando aí pra vocês um link da pesquisa. Essa pesquisa é somente pra vocês dizerem, disserem, falar pra gente o que vocês acharam da sessão de hoje. Se vocês gostaram, se vocês não gostaram, críticas construtivas pra que a gente possa melhorar e, quem sabe, já amanhã já trazer essas melhoras aí pra vocês. Beleza? Então o Leonan tá colando aí lista de presença pra vocês preencherem. Quem conseguir participar das três lives vai ter a mentoria gratuita na quinta-feira, né? E o formulário de feedback que pra gente é muito importante você dar a opinião aí do que você tá achando das sessões. Legal? Então, pessoal, scanem aí também QR Code, vamos bater esse papo, espero que vocês consigam entrar nessa turma do MBA aqui com a gente, mas independente nisso eu espero que vocês estejam aprendendo algo novo ou pelo menos reciclando algum conhecimento ou tendo outras visões pra você tomar a sua tirar suas próprias conclusões de como criar aplicações enxergar aplicações e esse tipo de coisa. Beleza? Maravilha, galera. Então, pessoal, um grande abraço para vocês. Muito boa noite. Fiquem com Deus. Eu vou sair daqui e vou correr, porque eu estou treinando para a meia-maratona e eu vou conseguir correr hoje de novo. Então, vamos nessa galera tudo de bom, boa noite aí e amanhã tem mais mesmo horário e a gente vai se falando, até mais galera