E aí A galera chegando aí Firme e forte galera vão ligando essas câmeras aí meu povo nada de nada de deixar quero ver um monte de gente toda bonitona aí empolgados uns caras com os bigode muito louco show de bola boa noite pessoal boa noite aí galera, firme e forte com vocês como é que vocês estão? boa noite boa noite pessoal boa noite boa noite boa noite boa noite boa noite boa noite Boa noite. Pô, liguem as câmeras aí, galera Tá, vamos com as câmeras aí ligadas Uma das coisas importantes aqui de hoje Vocês vão ver, vai ser a parte de interação A gente vai trabalhar em grupo A gente vai trabalhar separado A gente vai trabalhar de tudo quanto é jeito Então é importante pra caramba Se vocês puderem, por favor, realmente ligar a câmera aí Vai ajudar bastante, tá? Legal Esse PC não tem câmera Só por isso Tá, mas liguem aí, ó Gabriel Moretti, tem dois Gabriéis Lucas, Felipe aí Liguem as câmeras, galera Pra gente poder bater esse papo aí Tá o Marco, já tá com câmera Show de bola, meu povo Liguem as câmeras porque Hoje vai ter bastante coisa pra gente fazer, hein Vai mandar os careca Comentar de novo não, né? Ah, é verdade, né? Tem essa pegada. E aí, pessoal, como é que vocês estão? Semana começando, né? A gente tá com bastante gente aqui nesse momento, 410 pessoas. Show de bola aí, subindo. É, a semana começando. Muitos deploys pra fazer, começaram com muita coisa, como que se diz, muita coisa acumulada de sexta-feira. Olha, quem me dera. Quem me dera, um emendado aí, sempre sobe. Muita gemude pra preparar, né? A galera da gemude aí é fogo, hein? É. Sustentação também. Gemude da Terra e Pio, né, velho? Show de bola. Galerinha, seguinte, tá? Eu quero passar e dar uma ideia geral. Só tô esperando o restante aí da galera entrar. Provavelmente vai entrar mais gente ainda. Mas eu quero dar uma... Bom, primeiramente quero dar boas-vindas aí pra todo mundo. Queria saber alto, só tô esperando o restante aí da galera entrar, provavelmente vai entrar mais gente ainda mas eu quero dar uma, bom, primeiramente quero dar boas-vindas aí pra todo mundo, queria saber quem nunca participou de evento nosso aqui ou é a primeira vez que tá participando de um evento dessa forma, escreve aí não precisa nem escrever, pode até escrever no chat mas tem um joinha no Zoom, né? no Zoom a gente tem um joinha, que é diferente de mão levantada, tá? Mão levantada para perguntar, joinha para confirmar. Show de bola? Mas tem bastante gente que é a primeira vez aí, galerinha, sejam bem-vindos aí, galera. Fico mega feliz de saber que vocês estão aí. A dinâmica, né, de como que a gente vai trabalhar hoje é bem diferente de lives que a gente vai trabalhar hoje. É bem diferente de lives que a gente faz, é bem diferente de qualquer coisa que normalmente vocês veem a gente fazendo em canal do YouTube, etc. Normalmente, quem é aluno nosso, do nosso MBA, ou já participou de algum evento de Tech Week for Seniors no passado, deve entender mais ou menos o formato de como que a gente trabalha. Mas a nossa ideia vai ser o seguinte, meu povo. Durante três dias aqui, nós vamos focar em pilares que a gente considera super, mas super importantes para você conseguir não só desenvolver software, mas para que você consiga realmente trabalhar com grande aplicação adaptada, obviamente, nos dias de hoje. Então, se a gente pegar cinco anos atrás, a gente estava desenvolvendo aplicações de uma forma diferente. Se a gente pegar alguns meses atrás, a gente estava desenvolvendo aplicação diferente. Hoje, com o IA, a gente está trabalhando com coisas diferentes também. Então, o nosso mercado está mudando bastante, a nossa profissão está mudando bastante, mas tem duas coisas que eu tenho certeza que não vão mudar, tá? Uma coisa é fundamento forte que todo mundo precisa ter para trabalhar com qualquer sistema, qualquer inteligência artificial que vocês vão utilizar aí no dia a dia, né? Eu acho que o grande diferencial da nossa profissão como desenvolvedor de software daqui para frente vai ser muito ter clareza, muito nessa parte de arquitetura de software, arquitetura de solução, entendendo como que as aplicações funcionam, como que elas se comunicam. Sem esses fundamentos, simplesmente a gente vai ficar um monte de malucos na frente do cursor, dando next, next, next e torcendo pra tudo dar certo. E na realidade a gente sabe que a gente não quer desenvolver software assim. Tem muita gente desenvolvendo software assim hoje em dia mas a nossa ideia é que vocês consigam realmente ter fundamentos extremamente consolidados e fortes. E esse nosso evento aqui, ele tem um foco bem forte mesmo pra quem já é desenvolvedor sênior e que quer entender um pouco mais sobre arquitetura de software, arquitetura de solução, DevOps, SRE, a gente vai falar de IA. Então tem bastante coisa interessante que a gente vai trazer durante esses dias. E já peço para vocês aí de cara se preparem e bloqueiem as agendas de vocês para hoje, amanhã e depois. E também bloqueiem a agenda, principalmente porque a gente vai ter bastante experiência um pouco diferente. Ô, Leona, você consegue cortar o microfone da galera só para eu concluir meu raciocínio? O Leona está só para vocês saberem, tá galera? O Leonan é o nosso coordenador de toda a nossa área aqui das nossas pós-graduações e tudo mais, então deem um salve aí pra ele também. Mas, voltando ao assunto, meu povo, a nossa grande sacada aqui é a gente conseguir passar imerso durante três dias, cada dia vendo um assunto diferente, mas vendo esses assuntos aí se conseguirem se encontrar. Basicamente, a gente quer juntar as pontas também. Nós liberamos acesso à nossa plataforma com algumas aulas já para vocês. Quem aqui já teve chance de assistir algumas dessas aulas? A gente deixou disponível, inclusive a gente deixou um desafio lá pra vocês, que é o que a gente vai utilizar e o que a gente vai fazer hoje aqui, né? Teve uma galera aí que colocou. Show de bola. Maravilha. Tem gente aqui, o Wagner falando que eu tomei o Zenpique, cara. Nossa, galera, tem uma tara. Eu acho que eu tô tão bonito, galera, que a galera fica mais preocupado com o que eu tenho pra ensinar do que necessariamente de como que eu tô vestido. Daqui a pouco só aparecer de peruca, só vão falar isso, é isso? Mas, show de bola. Povo, seguinte. O lance vai ser o seguinte, então. Nossa primeira parte, hoje aqui, eu quero falar com vocês sobre System Design. System Design é uma das coisas mais importantes que a gente tem quando nós estamos pensando em desenvolver grandes aplicações. Por quê? Porque o System Design em si, ele vai possibilitar para a gente conseguir ter uma visão de alto nível de como os componentes, sistemas, serviços, eles vão se comportar em conjunto dentro de um ecossistema, tá? Hoje, praticamente, a gente não vive mais naquela época onde a gente só tinha sistemas monolíticos, né? Eu acredito que grande parte da galera, se vocês trabalham em empresas grandes aqui, provavelmente grande parte aí de vocês trabalham ou desenvolvem serviços, micro serviços no dia a dia. Como é que vocês estão aí, galera? Uma galerinha aí provavelmente trabalha já com micro serviços. É praticamente impossível nos dias de hoje a gente conseguir viver num ambiente grande sem trabalhar com micro serviços ou serviços, o nome que vocês querem dar. O grande ponto é que uma vez que você tem mais sistemas, esses caras precisam se comunicar. E uma vez que esses caras precisam se comunicar, a gente tem que conseguir ter um esquema de como vai funcionar esse mapa de comunicação. Ou seja, como essas soluções são desenhadas. Uma das coisas importantes também aqui que eu queria deixar claro aí para vocês é que a parte de System Design é importante aí para vocês, tanto para quem necessariamente está desenhando soluções dentro da empresa e precisa conseguir ter uma ideia geral de como tudo está funcionando e seus componentes e tudo mais mas também quem está buscando trabalho em grandes empresas afinal de contas, quem aqui já passou por lousa branca, galera? entrevista de system design quem aqui já passou por alguma? pode levantar a mão e pode falar, fala aí Gabriel conta pra gente como é que foi sua experiência, meu amigo opa, boa boa noite aí pessoal fiz a minha entrevista de recentemente, inclusive foi muito bacana porque assim fora do fim, né tirando o fim, você chegar no resultado é muito bacana o processo, né então, eles apontam algo. Ah, lá no meio da sua solução, você colocou aqui que você vai usar um load balance e tal, mas qual o algoritmo do load balance que você vai utilizar? O banco, o porquê desse banco? Ele está aberto para você, no futuro, abrir uma parte para histórico, auditoria, expôs dados e tal. E também a forma que você pensa. Eles deram um problema lá do nada e eu tive que pensar lá na hora como que eu resolveria em cima do desenho que eu tinha feito então foi bem interessante Show de bola galera, uma das coisas que eu tenho certeza aqui é que vocês vão ter uma clareza bem legal sobre System Design durante esses dias, inclusive hoje porque eu coloquei um desafio pra gente criar um System design do Instagram. Eu gerei ali alguns requisitos funcionais, alguns requisitos não funcionais, obviamente a gente vai tentar manter o escopo de tudo aquilo. E, obviamente, eu quero trazer sempre para vocês algumas dicas que vão ajudar vocês a focarem nesse system design para que vocês não percam o tempo e também dar algumas dicas que vão ajudar vocês a focarem nesse System Design para que vocês não percam o tempo e também dar algumas dicas, principalmente em relação a quem está ali em entrevistas, tá? A gente sempre gosta de colocar uma tecnologia a mais ou falar uma coisinha e quando você falou aquele termo, pronto. Aí o entrevistador vira uma lanterna exatamente naquela palavra que você falou e você fala, meu Deus, por que eu fui falar a palavra cáfica, por exemplo? Por que eu fui falar, não sei, qual tipo de banco de dados? Porque cada palavra que você fala, cada tecnologia que você usa, de alguma forma ou outra, você vai ter que mostrar algum nível de profundidade. E no final do dia, a grande ideia é você chegar a falar não sei. Ou seja, nunca ninguém sabe tudo de todos os detalhes de todas as tecnologias. A ideia é sempre a gente entender o nível de profundidade e normalmente baseado nas respostas e na solução que vocês acabam chegando, muitas empresas conseguem medir, vamos dizer assim, a sua senioridade. Então, dependendo da sua solução, uma solução mais para júnior, sua solução é uma solução mais para mid-level, uma solução mais para sênior, para staff, para principal. Então, eles vão esperando para cada tipo de solução e cargo, por exemplo, que você está aplicando, solu Para cada tipo de solução e cargo, por exemplo, que você está aplicando, soluções ou mais rebuscadas, ou que escalem mais, ou que sejam mais simples, mas ao mesmo tempo consigam dar conta. Então, vai depender muito do nível de maturidade de cada uma das pessoas que estão participando. Mas, independente de entrevista, isso acontece da mesma forma no mundo real, você dentro da sua empresa, na hora que você quer projetar, quer entender o ambiente e tudo mais, tá? Alguém aqui trabalha ou já trabalhou como arquiteto de solução? Levantem a mão, se alguém tem algum arquiteto de solução por aqui, ó, o Felipe fala aí Felipe, Luciano também fala aí, fala aí, Felipe. Luciano também. Fala aí, fala aí. Beleza? Fala aí, doutor. Fala aí, cara. O que você faz? O que um arquiteto de solução faz? Cara, bom, basicamente assim, a gente é meio que utiliza a Cláudia AWS, então a gente é mais focado em AWS. Então, o arquiteto é um cara que planeja, no meu ponto de vista, no meu conceito, ele é um cara que vai planejar toda a integração da sua aplicação dentro daquela cloud. Ou seja, ele vai pensar em quais serviços você vai utilizar. Se vai ser um EKS, se é um RDS, se se é um Kafka para você trabalhar com notificações entre microserviços dentro do seu EKS né se seus microserviços vão utilizar mais de um dois três bancos de dados independentes se você vai utilizar um Aurora para auto scaling de determinado banco de dados então no meu ponto de vista o o arquiteto é o cara que vai pensar na estrutura de serviços do sistema. Show de bola. Mais alguém? Francisco Miguel. Bota a câmera aí, galera. Bota aí, Francisco. Bota aí, Jonathan, a câmera. Para vocês falarem rapidinho aí a experiência de vocês aí como os arquitetos de solução. Cara, boa noite. acabei de chegar do futebol aqui e já vim para essa live aqui. Então, o conceito de arquitetura de solução em algumas empresas que eu trabalhei, principalmente, pode falar o nome da empresa? Pode, fica à vontade, só não fala mal. No caso, eu trabalhei muito tempo na CIT, né? Então, lá ela tem várias camadas de arquitetura entre os times. Aí no ecossistema de arquitetura de software é muito aplicado a solução para o time. Quais são os componentes? A cloud geralmente é definida pelo cliente. Mas quais são os componentes que o time vai usar para poder desenvolver os fluxos ali? E aí a arquitetura de solução, ela trata mais parte de pessoas, agenciamento de pessoas, custos e a integração desses pequenos sistemas, ecossistemas com ecossistemas maiores ali da empresa em si. Ou seja, eu tenho um sistema de pagamento integrado com um sistema de entrega e aí a arquitetura de solução vai fazer a equalização de tudo isso dentro de uma empresa ou de um cliente. Show! Caras, é interessante a gente ver porque é o seguinte, é importante eu vou tentar deixar até claro, vou até compartilhar minha tela aqui, porque vai ficando, inclusive, mais fácil de a gente... Wesley, uma dúvida, já que surgiu aqui, um DevOps, ele sempre vai ser um arquiteto ou não é uma regra para isso? Não, não, não. São coisas distintas. Na realidade, na minha opinião, é bem distintas. É que o cara de DevOps normalmente ele acaba tendo contato com as soluções e as entregas das soluções de outras pessoas, mas uma pessoa de DevOps não trabalha ali como arquiteto de solução e isso aqui é importante a gente deixar claro galera, deixa eu compartilhar minha tela aqui. Screens. Deixa eu colocar aqui. Vocês estão conseguindo ver minha tela aí? Sim. Deixa eu botar o chat aqui também. Onde está o chat do Zoom? Para eu conseguir ficar vendo vocês aqui num outro monitor. E também eu tenho que fazer uma parada aqui para as pessoas não ficarem fazendo anotação na minha tela. Show de bola. Pessoal, aqui é onde a gente vai trabalhar em cima hoje, mas de forma geral, tá? Quando a gente está falando de arquitetura de solução, nós estamos falando de alguns pontos importantes, tá? Nós estamos falando de ligação barra ou componentização de um ecossistema. Essa que é a grande sacada. O grande ponto é que hoje em dia nós temos muito cloud providers. Nós temos diversos cloud providers e nós temos muito cloud providers, tá? Nós temos diversos cloud providers e nós temos muitos serviços prontos que ficam mais fáceis a gente conseguir grudar um serviço, uma solução na outra, que foi o que o nosso camarada falou, trabalha mais com AWS, por exemplo. Então, quando a gente está falando, por exemplo, em AWS, a gente tem aquele um trilhão de serviços e, normalmente, arquitetos de solução focados em AWS conhecem de trás para frente toda aquela gama de serviços e quando um cliente precisa, olha, eu preciso ter um servidor, esse cara precisa se comunicar com outro cara, esse cara aqui precisa manter uma conexão persistente, aí eu preciso utilizar esse banco de dados, mas daí eu vou precisar fazer conversão de vídeo, e aqui eu vou precisar trabalhar com fluxo. Então, quando a gente começa a entender todo aquele problema, a gente começa a cair na componentização. Então, hoje em dia é muito comum você ver pessoas falando que são arquitetos de solução focados em uma determinada cloud. Mas, independente de cloud, é importante vocês entenderem que o arquiteto de solução, ele vai sempre falar de componentes, ele sempre vai falar de custo, ele sempre vai falar de risco, tá? E ele sempre vai falar, tá? De... Ele vai sempre... Vai ser no final das contas, nas contas, trade-offs. No final das contas, trade-offs. No final das contas. Ou seja, se você escolhe uma solução e você não sabe o ponto negativo dela, em tese, você não deveria estar escolhendo essa solução. Então, o arquiteto de solução vai ter que entender de componente, de custo, de risco e, principalmente, de negócio. Se você não entende do negócio da sua empresa, simplesmente ficar grudando pedacinhos de uma aplicação com a outra não vai significar nada. Quando a gente está escolhendo uma arquitetura ou a gente está grudando esses componentes, a gente tem uma parada que chama TCO, que é Total Cost of Ownership. O que isso significa? Qual é o custo todo para você fazer o desenvolvimento daquilo. Mas não é apenas pra fazer o desenvolvimento, é pra fazer o setup, é pra manter aquele negócio funcionando e também pra desativar. Quem aqui já trabalhou em algum projeto que em algum momento esse projeto foi abortado ou você trabalhou num sistema que em algum momento esse sistema teve que ser removido totalmente porque a empresa mudou ou modernizou a sua infraestrutura e tudo mais. Uma das coisas que poucas pessoas conseguem e colocam na conta é essa parada. Desativar sistema custa muito caro também. Então, quando a gente começa a olhar todos esses pontos aqui, a gente começa a olhar todos esses pontos aqui, a gente começa a perceber que a arquitetura de solução, ele não está ligado necessariamente apenas qual é o serviço que eu quero trabalhar ou como. Obviamente de uma forma mais tática, que é o que a gente vai fazer hoje aqui, a gente vai ter muito desenho. Eu gosto de tirar sarro que arquiteto de solução fica desenhando no Scalidro, fica desenhando no Scaledraw, fica desenhando todo dia e criando PowerPoint. Mas, no final das contas, tem muito disso, mas também tem muito de entender sobre custo, risco, trade-offs para saber se aquela solução realmente é adequada e não colocar aquela solução somente porque ela é mais legal e ter muito clareza se o que ela tem de bom o que ela tem de ruim, porque que essa decisão está sendo tomada quais são as implicações quais são os custos de tudo isso aí então a gente sempre tem que ficar ligado com tudo que a gente tem de falar sobre arquitetura de solução pontos importantes aqui também pessoal, toda vez que a gente tem de falar sobre arquitetura de solução. Pontos importantes aqui também, pessoal. Toda vez que a gente está falando em arquitetura de solução, a gente tem que conseguir pensar em como que essa solução vai ser desenvolvida. E toda vez que a gente pensa em como a solução vai ser desenvolvida, nós temos duas coisas. Nós temos requisitos funcionais e requisitos não funcionais. Certo? Os requisitos não funcionais e funcionais, eles vão definir como a sua solução vai ser desenhada. Por quê? Porque com os funcionais, eles vão trazer para a gente o que a gente vai precisar desenvolver em si. Quais são os serviços? Quais são os sistemas? Como é que aquilo vai funcionar? Os não funcionais, ele vai trazer como que vai ser o comportamento desse sistema dentro das funções que eu tenho. E esses requisitos não funcionais, eles mudam completamente a forma de como os requisitos funcionais vão ser desenvolvidos. Por exemplo, se eu tenho que desenvolver um sistema que tem mil acessos diários, né, pra várias pessoas, sei lá, ficarem gerando relatório, é uma coisa. Se eu tenho um sistema que faz exatamente a mesma coisa, mas para um milhão de pessoas, o sistema da forma como ele vai ser desenhado vai ser totalmente diferente. Então, é muito complexo você sair definindo qualquer coisa de como você vai criar um sistema hoje sem ter requisito funcional e não funcional. Uma das coisas que eu sei de uma forma bem clara nas empresas é que nós estamos muito acostumados a olhar requisitos funcionais. A gente tem, não digo que é uma mania, é uma cultura muito grande nas nossas empresas. As empresas vão lá e falam, olha, a área de produto, a gente tem esses caras, esse negócio vai ter que funcionar assim, vai funcionar assado, vai ter que fazer isso, vai ter que ficar aquilo, e a gente vai lá e vai desenvolver as nossas features. O ponto principal aqui é, esses requisitos não funcionais, e a gente vai falar um pouco mais deles daqui a pouco, eles são os caras que vão moldar como essas funções vão ser desenhadas. Muda completamente. E o mais interessante é que conforme você vai modelando o seu sistema baseado nesses requisitos, mais complexo o seu sistema vai ficando. Lembrando que complexidade num software é algo que não dá para escapar. A complexidade sempre vai subir. O máximo que a gente pode tentar é diminuir essa curva de subida da complexidade, documentando bem, desenvolvendo bem, tendo boas práticas de desenvolvimento, tendo uma boa arquitetura, mas o fato é que todo software vai crescer para sempre a complexidade. Se você tem mais código-fonte no seu código todos os dias, maior vai ser a complexidade que o seu sistema vai ter. Então, se eu tenho aqui código-fonte, né, e eu tenho aqui o tempo, isso significa que eu vou ter aqui a minha complexidade, como é que ela vai trabalhar. Eu até fiz um vídeo esses dias no canal do YouTube, falando sobre Vibe Coding. Quem aqui assistiu, galera? Vídeo de Vibe Coding. E eu mostrei exatamente essa curva falando que o Vibe Coder, o cara que não sabe programar, o grande problema não é que o software dele não funciona, ele funciona. Mas o nível de complexidade dele ao longo do tempo é tão grande que o software fica impossível de se manter. E esse é o grande ponto. A nossa diferença, como bons desenvolvedores, é fazer com que essa curva fique menos acentuada para que a gente não queira reescrever software. Porque nós temos vontade todos os dias de reescrever o software. Afinal de contas, quem aí não gostaria de poder começar do zero aquele software chato que você está mexendo no sistema, que foi algum cara que fez há 10 anos atrás e você está ali sofrendo com ele? Acho que todo mundo já deve ter passado por situações desse tipo. E eu acho que a grande sacada aqui é exatamente essa. A gente conseguir tentar equacionar, equalizar essa complexidade aí no dia a dia, tá? E trabalhando com arquitetura de solução, isso é uma forma. Mas essa forma, ela acaba englobando não um único sistema. Engloba diversos sistemas e nesse caso a gente pode chamar até mesmo de componentes. Cada sistema pode ser considerado um componente ou cada integração entre sistemas pode ser considerado componente. O ponto importante é que a arquitetura de solução vai nos ajudar com isso. Quando a gente está falando em arquitetura de solução, e aqui a gente vai falar hoje sobre o System Design do Instagram, e vocês vão ter uma atividade bacana para fazer, inclusive, em conjunto, vocês vão perceber, eu vou dar esse exemplo aqui, próprio Instagram aqui para vocês, é o seguinte, nesse nosso desafio que a gente vai trabalhar, você vai perceber que eu trabalhei bem pesado com somente três requisitos funcionais. O usuário, ele vai poder criar novos posts com possibilidade de fazer upload de imagens e vídeo. O usuário poderá seguir outros usuários e também pode ser seguido. E o usuário terá acesso ao feed com post dos usuários que ele está seguindo. Ponto. Ou seja, se eu falo que eu vou desenvolver isso, eu vou desenvolver isso e somente isso. Agora, tem uma diferença muito grande de criar três features dessa forma para um sistema que vai rodar 100 pessoas ou de um sistema que vai ter 100 milhões de usuários utilizando por dia. Entende? Então, esse tipo de coisa é o que faz a separação, na minha opinião, de um bom desenvolvedor, de um bom arquiteto, de uma pessoa que daqui pra frente vai estar sendo exigido cada vez mais, né? Não adianta a gente falar ou estar naquela fase de negação, mas inteligência artificial, sim, vai tirar muitas funções comuns que nós fazemos no dia a dia. Muita coisa que a gente faz repetitiva no dia a dia vai acabar, vai ser feito completamente por inteligência artificial. E o que vai sobrar vai ser você com o seu conhecimento, com a sua experiência, com os seus fundamentos claros em desenvolvimento e em arquitetura de software, para que você consiga utilizar essas ferramentas de inteligência artificial para ser mais produtivo, para entregar mais. Então, galera, muita, mas muita coisa daqui para frente vai ter que ser resolvida, baseado no seu repertório e na sua experiência e naquilo que você estudou de fundamento. Aquele seu framework que você adora, aquele Spring maroto, o Laravel do PHP, a galera do Python, o .NET. Galera, isso aí, cada vez mais vai virar detalhe. Eu lembro uma época que eu ficava o tempo inteiro tentando decorar os métodos daquele meu framework, que me deixava mais produtivo, daí começou a ter autocomplete, depois as coisas foram avançando, e daqui pra frente, o que vai restar bastante pra gente é conseguir usar a nossa inteligência em entender negócios, entender pessoas, entender componentes, entender sistemas e ecossistemas para, sim, esses sistemas a gente conseguir desenvolver. E aí vão ter C&As desenvolvendo, vão ter nós desenvolvendo, vão ter agentes conversando e desenvolvendo. Tem um futuro longo aí pela frente, não dá para a gente saber como vai ser. O grande ponto que eu tenho certeza é, hoje você precisa ter muitos conceitos e fundamentos aí, tá? E o nosso objetivo hoje aqui vai ser, sim, trabalhar com um system design que a gente vai, obviamente, fazer de uma forma simples, mas como se a gente pudesse estar passando, inclusive, em uma entrevista de System Design no dia a dia. Então, como que vai ser a dinâmica de hoje, amanhã e depois? Hoje, a gente vai focar estritamente nesse System Design. Amanhã, a gente vai falar bastante entre comunicação entre sistemas e a gente também vai falar bastante sobre inteligência artificial, tá? Depois da manhã, nós vamos falar sobre DevOps, SRE, e a gente vai falar ainda mais também sobre a parte de inteligência artificial, tá? Então, é importante que vocês participem desses três dias, vão ser algumas sessões, acredito que longas. Mas eu espero que no final desses três dias vocês possam pensar o quanto vocês aprenderam. Vocês podem já sair utilizando o que vocês estão aprendendo no dia seguinte. E também ter alguns pontos de reflexão sobre o que você tem que aprender e o que você quer de futuro aí na sua profissão, o que você quer dar, qual que vai ser o seu próximo passo aí na sua profissão. Beleza? Então, essa que é a nossa ideia aqui de hoje. Então, quando a gente for falar do System Design, eu vou pedir para vocês pensarem quais são as entidades relacionadas ao nosso Instagram, ou seja, pensem nos substantivos que a gente tá dando, né? Se eu tenho um usuário, se eu tenho um carrinho de compras, se eu tenho um post, se eu tenho... Não interessa, pensem nas entidades principais que vão fazer parte de você conseguir cumprir esses três requisitos funcionais. Uma outra coisa importante aqui para vocês também é conseguir, pelo menos, mapear as principais tabelas. Não precisa ser tabela necessariamente de banco de dados relacional, mas modelar dados. Quais informações vão estar guardadas como, tá? Quais são tipos de bancos de dados que a gente pode utilizar para desenvolver esses tipos de aplicação. Também eu quero que vocês pensem em como que eu vou desenhar a minha API para que eu consiga cumprir esses três requisitos, ou seja, quais são endpoints que eu posso ter para eu conseguir fazer com que esses caras funcionem. Então, não pirem em relação a isso também. E por último, e não menos importante, eu preciso que vocês pensem em como vai funcionar o desenho da nossa solução. Por exemplo, eu posso ter um usuário que vai bater num determinado serviço, aí esse serviço vai chamar um banco de dados, e aí esse meu banco de dados vai trazer informação aqui para ele. Eu não preciso que vocês pensem tudo isso de uma forma extremamente desenhadinha, bonitinha, mas eu preciso que fique claro pra que qualquer pessoa que olhe o desenho de vocês, consiga entender o fluxo de como que as informações estão andando, tá? É importante que quando eu olho pro seu System Design, vá ficando cada vez mais claro aonde você está focando. Mas a dica principal que eu quero dar para vocês aqui hoje vai ser o seguinte. Para cada endpoint da API que você for fazer, vai ter que suprir um requisito funcional. E para cada endpoint desse, você vai ter um suprir um requisito funcional e para cada endpoint desse, você vai ter um desenho feito. E quando esses desenhos estiverem compostos, significa que você conseguiu cumprir esses requisitos funcionais. Por outro lado, feito isso, eu preciso que vocês olhem esses requisitos não funcionais e olhem para o desenho que vocês estão criando e pensem, poxa, será que esse único serviço daria conta de, dar conta desses 100 milhões de usuários por dia? Será que acessando tudo nesse banco de dados eu consigo fazer todo o processamento de um feed e ainda ter uma latência baixa de 400 milissegundos? Será que com o que eu estou fazendo eu consigo priorizar disponibilidade ao invés de consistência ali nos meus dados? Então, esses tipos de coisa são pontos que você sempre tem que fazer um double check no seu desenho. Então, você desenhou, você pensa, está cumprindo esses requisitos? Está. Desenhou? Está. Está conseguindo cumprir esses requisitos? Ótimo. Então, em tese, você concluiu aí o seu system design. Então, essa que é a ideia principal que eu quero que vocês pensem e trabalhem ali hoje. Como é que vai funcionar essa dinâmica, pessoal? Vai ser o seguinte, a gente vai quebrar vocês em grupos, grupos de sete pessoas, porque às vezes você pode cair num grupo que alguém esteja logado, mas a pessoa não esteja ali na frente. Então, sete pessoas, a gente consegue garantir o mínimo de pessoas trabalhando. Recomendo que vocês utilizem o Scaledraw, tá? Tem versão gratuita, mas vocês podem utilizar também o software que vocês quiserem para desenhar. Isso, para mim, é o de menos, tá? E um ponto aqui pra vocês que é super importante. Pensem, reflitam em conjunto, mas tentem ser o mais objetivo possível, porque nós vamos dar pra vocês 45 minutos pra fazer isso, tá? Ou seja, é um tempo bem puxado pra fazer algo complexo. A nossa ideia não é fazer com que vocês consigam fazer o melhor System Design do mundo, mas a ideia é que vocês, em conjunto, consigam, pelo menos, encontrar o caminho das pedras dessas soluções. Assim que a gente fizer, vocês fizerem esse System Design em conjunto, a gente vai voltar para a tela principal, eu vou chamar aí uns dois grupos pra apresentar e a gente discutir o System Design que eles fizeram, então vocês vão poder compartilhar a tela e tudo mais, aí eu vou dar minha opinião, a galera vai poder dar opinião, a gente gera um debate, e depois, em cima disso, eu vou mostrar como eu aqui tô resolvendo e daí a gente debate esses assuntos. Então, esse aqui é o nosso principal objetivo aqui de hoje para a gente conseguir trabalhar. Legal? Pontos importantes também que eu não posso deixar de levar em consideração, tá, galera? Isso aí é importante também. Pessoal, seguinte. Tudo que vocês estão vendo aqui hoje e tendo esse tipo de experiência, é algo muito parecido, tá? Com o que a gente disponibiliza no nosso MBA em arquitetura full cycle que nós temos. Pra quem não conhece a gente, nós somos uma empresa de cursos de treinamento chamado full cycle, mas nós também temos uma faculdade e essa faculdade ela chama FCTec, que treinamento chamado Full Cycle, mas nós também temos uma faculdade e essa faculdade ela chama FCTec que é a faculdade Full Cycle de tecnologia onde a gente tem um MBA em arquitetura Full Cycle vou até aproveitar para fazer um jabá rápido aqui para vocês esse nosso MBA ele tem um foco bem grande em que em arquitetura de soluções em arquitetura de software, em DevOps SRE e soft skills. A gente também está adicionando pontos importantes em relação à parte de inteligência artificial. Essas aulas do MBA, elas são gravadas e também com encontros ao vivo como esse aqui. Então, a nossa ideia sempre é, você vai ter conteúdo gravado, que você vai assistir, vai acompanhar, e você vai ter aulas ali, ao vivo, comigo e com diversos especialistas. A gente tem aqui, desde Uncle Bob que gravou aulas com a gente, o Elemar, o Van Vernel, que é o criador do livro Vermelho, do DDD, né? A gente tem o Fabian, também, da Microsoft, que vermelho do DDD, né? A gente tem o Fabian também da Microsoft, que é um cara especialista em System Design, tem o Rodrigo Branas, o Fernando da Google, tem uma galera fantástica aqui que dá aula e também faz participação. Então a nossa ideia nessa semana aqui da Full Cycle Tech Week for Seniors é também dar pra vocês uma experiência mais próxima possível do que é estudar com a gente no dia a dia. Hoje, todo mundo que está acessando e se inscreveu no evento tem acesso à nossa plataforma, onde vocês têm acesso às aulas que a gente disponibilizou de System Design, com apítulo também de comunicação e DevOps SRE também. Então, acessem, vejam o e-mail que vocês receberam, vocês também podem acessar a nossa plataforma para também assistir essas aulas, tá? Uma coisa importante também para eu falar aqui para vocês é o seguinte, nós estamos num momento de pré-matrículas do nosso MBA e quem fizer a inscrição agora consegue ter um baita desconto de pré-matrícula porque as aulas vão começar somente em junho, tá? Então, cliquem nesse link ou eu também vou copiar esse link aqui. Deixa eu tentar abrir um link no meu... Nesse QR Code, tá? Acho que vocês estão conseguindo ver esse QR Code aqui também, né? Escanei esse QR Code. Esse QR Code vai tá? Acho que vocês estão conseguindo ver esse QR Code aqui também, né? Escaneie esse QR Code. Esse QR Code vai fazer com que vocês caiam nesse form. Basicamente é preencher nome, e-mail e alguns dados que podem aparecer para você. A nossa equipe entra em contato com você. A gente bate um papo, entende o seu momento profissional. E quem sabe você vem estudar com a gente. A gente vai dar todos os detalhes que você precisa saber, então é totalmente aí na faixa, a gente vai entender realmente o momento que você tá, pra ver se vale a pena você estudar aí com a gente tá, então, jabá dado aí pra vocês, aproveite porque se eu não me engano são é uma boa grana de desconto em relação pra pré-matrícula aí pra vocês, maravilha? então aproveitem desconto em relação pra pré-matrícula aí pra vocês. Maravilha? Então, aproveitem e entrem aí. Tem gente perguntando qual stack do portal que você utiliza. Cara, a gente tem diversos sistemas que rodam pra gente. A gente roda PHP, Python, a gente tem Go, a gente tem bastante coisa rodando por trás dos nossos sistemas. Maravilha? Então, galera, o lance é o seguinte, tá? Eu vou colar esse link aqui pra vocês também aqui no chat tá? esse link tá inclusive no desafio que eu deixei pra vocês no nosso portal, né? que vocês tem acesso, mas eu tô passando aqui pra vocês, porque esse link, ele tá trazendo as orientações mais claras pra você poder fazer o System Design Design em conjunto com o seu grupo. Então, basicamente, a parada é a seguinte. Estão todas as especificações aqui. É muito do que eu já mostrei aqui nesse nosso Scaled Draw, mas a gente tem alguns outros detalhes para garantir que vocês não vão querer abordar temas que vocês não precisem abordar então a ideia é que vocês foquem realmente nesses requisitos para vocês conseguirem trabalhar fechou? maravilha meu povo então o que eu vou fazer agora aqui vai ser o seguinte, eu vou pedir para o Leonan deixa eu descompartilhar minha tela eu vou pedir pro Leonan aqui, quebrar vocês em grupos de sete pessoas, tá? e aí na hora que vocês se quebrarem em grupos vocês vão se apresentar falar rapidamente do com que vocês trabalham, com a experiência de vocês aí um de vocês pode ser o piloto, vocês compartilham a tela ali no Zoom mesmo e comecem a rabiscar, tentem trabalhar em conjunto e tentem ser o mais produtivo e direto possível, porque tem bastante coisa que dá para a gente fazer aí nesse System Design. Vou pedir também, galera, por favor, tá? Seguinte, liguem as câmeras pra deixar um ambiente muito mais bacana, mais sociável. Você tá falando com outras pessoas, então liguem as câmeras, é muito mais bacana do que você ficar falando com ninguém aí, tá? E por último, tá? Eu sabia que o Leonan iria querer dar esse recado, mas é importante eu dar também, é que vocês vão entrar em salas. As salas de vocês, elas vão ter um número, tá? Decorem o número dessa sala. Por quê? Porque uma vez que você entrou nessa sala, simplesmente o que vai acontecer é que você vai estar lá com a galera, se a sua conexão cair, se você saiu, entrou de novo, você vai entrar na nossa sala principal e você vai pedir, por exemplo, para o Leonan falar, Leonan, eu estava na sala número 7, me bota lá de novo, tá? Então, isso aí é um ponto importante. Se você cair em alguma sala e só tem um monte de gente que ninguém tá falando nada, sai da sala, fala com o Leonel, Leonel, me bota em uma outra sala porque eu caí aqui, não tem ninguém participando. Eu acho bem difícil, né? Porque a gente tá colocando sete pessoas aí por sala, mas a ideia é que sempre vocês decorem o número da sala de vocês. Se você não decorou, caiu aqui, voltou de novo, a gente vai jogar você pra uma sala randômica e daí você vai fazer novos amiguinhos aí também. Maravilha? Galera, três minutos para dúvidas rápidas. Alguém tem alguma dúvida que queria tirar em relação à dinâmica em si? Pode levantar a mãozinha. Aqui o Elias. Bota a câmera aí, Elias. Fala com a gente só com câmera, fechou? Fala aí, garoto. Tá. Eu, cara, eu fiquei na dúvida é o seguinte. A gente vai cumprir os requisitos funcionais e não funcionais. É isso? Exatamente isso. O desenho final, o design de API, banco de dados, basicamente tudo que você está falando ali, o final de tudo é gerar o desenho do System Design. Esse desenho tem que cumprir basicamente os requisitos funcionais e não funcionais. Essa que é a ideia. Fechou? Luciano, levantou a mãozinha aí também? Só para compartilhar com todo mundo. O Leonan é também conhecido como arroba deve full cycle, deve sei lá o quê. Arroba deve full cycle, é. Isso, e outra, estão também compartilhando o link aí, que estão perguntando no chat aqui, de quais são os requisitos, tá? Tô tentando ajudar, desculpa aí. Ah, não, que é isso. Galera, o lance dos requisitos, eu colei o link aqui pra vocês do Notion, tá? Tá aí no chat, por favor. Depois a gente manda via broadcast nas salas de todo mundo pra garantir que ninguém vai perder, tá? Mas é aquele documento do Notion que eu mostrei ali para vocês. Bacana? Mais alguma dúvida, galera, em relação à dinâmica? Como é que vai funcionar? O APSM. Bota a câmera, meu amigo. Tinha levantado a mão e... Amiga, desculpa. Qual que é o seu nome? Ana Paula. Você tinha comentado, enquanto estava explicando, que a gente tem que criar um endpoint para cada requisito? É isso? Isso. Normalmente, eu costumo simplificar dessa forma. Por quê? Vamos imaginar que eu preciso criar um post. Eu vou postar algo no Instagram. Então, um endpoint ali naquele momento é o que consegue represent que eu preciso criar um post. Eu vou postar algo no Instagram. Então, um endpoint ali naquele momento é o que consegue representar eu criando aquele post, por exemplo, entendeu? Então, como são três requisitos funcionais, eu recomendo que você faça pelo menos três endpoints. A principal dica que eu tento dar sempre aí pra vocês é nesse caso aqui, mais é menos. Quanto menos endpoint você colocar é melhor, quanto menos tecnologia você colocar é melhor. Por outro lado, não adianta colocar um cliente chamando um sistema, chamando um banco de dados. Você não vai conseguir cumprir os requisitos funcionais e não funcionais somente com isso, tá? Mas sempre pense em quais são as entidades que você vai ter, baseado nessas entidades, como que vai ser a modelagem delas, né? Os dados, de como os dados delas vão ser organizados, e quais são as ações que a gente vai poder fazer. Essas ações, normalmente, são os endpoints, o nosso API design, de forma geral. E aí, nesse API design, você pode colocar posts, barra posts, passando os dados do post, por exemplo, entendeu? Ah, eu quero ver o feed, barra feed, coisas desse tipo. Daí você pode colocar, retornou um 201, retornou uma lista de posts, por exemplo. Então, vocês não precisam ficar também especificando as coisas no detalhe, se é um inteiro, se é uma string, esqueçam isso. Quem olhou o ID sabe que é um ID. Se você cai numa entrevista, ninguém vai perguntar se aquele ID é string ou inteiro, a não ser que ele queira, sei lá, entender como é que você está pensando a indexação no banco de dados. Entendeu? Mas sempre tentem fazer da forma mais simples possível aí nesses casos. Fechou? beleza, obrigada eu tinha falado antes, mas vou fazer só uma pergunta você vai passear nas salas? eu vou passear em sala sim eu não sei se eu vou conseguir passear em todas porque tem bastante salas mas a gente vai eu vou dar uma passeada assim pra bater num papo aí com vocês fechou? uma dúvida aí também é precisa ser no Scaledrop ou pode ser no pode ser em qualquer aplicação eu uso bastante Scaledrop porque ele é bem fácil mas se você quiser usar Draw.io pode usar o que você quiser o importante mesmo é conseguir ter um desenho no final para a gente conseguir olhar. Maravilha? Então, fechou. Leonan, é com você agora aí o microfone. Eu também vou me preparar aqui para eu também organizar meu material. Eu quero dar uma revisada. Eu já tenho, obviamente, meu System Design pronto para eu não ter que ficar gastando o tempo de vocês na hora que eu for fazer a minha versão. Então, vou dar mais umas revisadas, tem algumas coisas que eu não tô muito contente com ele aqui, inclusive. Fechou? Leonão, manda vir aí no microfone e organiza aí o pessoal. Estão satisfeitos com o resultado final? Muito bom. Acho que sim. Final não, resultado de começar, né? Parcial, parcial. Pensei que você já estava até com o código do Instagram feito pra mim, pô. Você pediu pra gente desenhar a arquitetura em 50 minutos, pô? O código tá com... Tá quase de asa. Um show de bola. E aí galera, o que vocês acharam aí? O pessoal tá voltando ainda, né Leonardo? tá, o pessoal tá acabando de voltar top demais a dinâmica show de bola curtiram? foi bacana foi a época de pós-graduação no IPOG foi um negócio rápido 40 minutos pra decidir uma estratégia passou muito rápido tipo se vira rápido, né, 40 minutos pra decidir uma estratégia. Passou muito rápido, hein? Tipo, se vira nos 30 do Faustão. É, passou muito rápido. Se vira nos 45, esse. É. Quando a gente dupla só 20 minutos. O segundo lá, tentando resolver. E bora. Mas eu vou dizer uma coisa aqui pra vocês agora vai chegar um momento tem gente voltando ainda ou Leonardo? não, não, já tá todo mundo aqui, agora podemos dar continuidade então é o seguinte, já tem muita gente aí feliz, falou que conseguiu fazer, que está satisfeito blá blá blá, agora eu queria saber o seguinte, eu quero pegar pelo menos, vai depender muito do tempo da análise, né? Mas eu queria pegar aí pelo menos dois grupos que fizeram para a gente bater um papo em cima do System Design aí de vocês. Qual grupo que vai levantar a mão primeiro? Ah, o Vinícius já levantou. Ele falou assim, ó, aqui tá garantido, né? Cara, vamos fazer só o seguinte, eu vou mutar todo mundo aqui, inclusive vou te mutar, e daí eu te peço pra você desmutar aí. Show, tô desmutado. Aí, só aceitar aí pronto, bom, temos aí o Vinícius galera, quem quiser participar também na palha do grupo, câmera ligada tá, aí não vai ter jeito então é o seguinte, ó, Vinícius a gente tem uma fila aí do Sérgio do Guilherme, do Flávio porém, tá, vai depender muito do tempo que a gente vai ter, do tempo dessas análises, porque eu não quero deixar todo mundo aqui até as 11, meia-noite, pra gente bater nesse papo. Somente pra todo mundo lembrar, a nossa ideia agora vai ser pegar o trabalho, por exemplo, que o Vinícius fez aí, o grupo dele, tudo mais, entender o system design deles, e depois disso Vinícius fez aí, o grupo dele, tudo mais. Entendeu o system design deles. E depois disso, eu vou pro meu system design e daí a gente discute em cima, a gente troca uma ideia, daí pra gente ir pro final. Fechou? Vinícius, cara, compartilha a tela aí do seu computador, cara. Leonardo, dá permissão aí pra ele. Vinícius na fogueira aí. Não adianta botar ele. Vinícius na fogueira aí. Não adianta botar só Vinícius. Quem tava no seu grupo aí tanto? O meu grupo era Wesley, o Everton, Marcelo, tinha o David também. Eram muitos nomes. Pô, deixaram você sozinho aí, cara? Não, os caras fizeram. A gente discutiu bastante lá no grupo. Dá suporte aí pro Vinícius aí no chat, galera. Compartilha aí pra nós. Uma discussão boa. Tá vendo minha tela? Tô vendo sim. Tá muito pequeno ou tá normal? Não, tá de boas. Eu acho que só na parte dos desenhos depois vai ter que dar uma aumentada. É, vai ter que dar uma aumentadinha então o que a gente como a gente começou na verdade a gente começou identificando quais eram as entidades de fato do do sistema a gente identificou como entidades principais os users o content e o post e aí content a gente disse que era o texto ou vídeo ou imagem e o post seria alguma coisa que pudesse juntar isso tudo, porque nos posts a gente pode ter junção de texto com imagem, ou de texto, imagem, vídeo, enfim. Então, a gente fez meio que essa separação, a gente identificou como coisas diferentes. Até porque o post vai pertencer a algum usuário, e não necessariamente aquela imagem também vai pertencer àquele usuário em si. Então, foi mais ou menos esse o pensamento. E aí, com as entidades formadas, pensadas, a gente foi para a criação dos endpoints em si. Então, a gente fez o endpoint do Criapost, que é um método HTTP post, aí vem users, esse ID seria o ID do usuário e o conteúdo que ele está criando. Então a gente pensou que o conteúdo que ele criaria seria alguma coisa que seguiria esse modelo, seria um cara que tivesse um type do tipo text, ou vídeo, ou image, e o payload, que seria de fato o conteúdo que ele está criando, seria o conteúdo ali que ele está levando, seria o conteúdo que ele está levando. O outro endpoint seria o de seguir o usuário, seria o users e barra o ID do usuário que ele está seguindo. É isso? É isso. E o terceiro seria o de acessar feed, que seria um get com o user's UID, que é o UID do usuário que está logado para pegar todos os posts, para carregar o feed dele, dos usuários que ele seguiu. Então, o primeiro caso seria ali, a gente tem um conteúdo, ele vai enviar esse conteúdo para um serviço, e aqui a gente fez uma separação, porque se esse conteúdo for vídeo ou imagem, a gente decidiu salvar ele num bucket, e desse bucket a gente vai ter um path. Porque fica mais fácil a gente manipular esse path do que ficar manipulando os dados de imagem ou de vídeo. E o texto já é simples também. Então, no final das contas, para salvar no bucket, a gente sempre vai ter um texto. Então, a gente pensou nesse tipo de caso. Show? Perfeito. Basicamente isso. No fim, a gente salva esse post no banco. Relacionado ao usuário e tal. O segundo ponto seria o de seguir o usuário. Então, é... Um outro ponto. Esses services, a princípio, eles são iguais. Tanto os services quanto o banco. A gente só separou para ficar mais organizado. Mas seria o mesmo banco, o mesmo serviço. Show? Perfeito. A segunda parte é de seguir o usuário. O usuário vai enviar essa requisição lá para o serviço. E vai ser um post também com a id do usuário que ele tá sendo que ele quer seguir e no conteúdo também tá indo o id do usuário que tá seguindo então meio que a gente faz esse e salva essa requisição lá no banco né talvez se relacionamento lá no banco e o terceiro agência Salfeed, que ele vai fazer esse get, vai pedir pelos usuários que ele seguiu, o post dos usuários que ele está seguindo. E aí a gente retorna esse dado para o front, para o usuário que pediu. Basicamente, a gente funciona nesses três casos. Wesley, acho que você tem que aceitar aí. Agora foi. Cara, beleza. Eu percebi aí que vocês focaram bastante nos requisitos funcionais e tudo mais. vocês focaram bastante nos requisitos funcionais e tudo mais. Agora, vocês fizeram algum outro tipo de design que consiga mostrar isso, conseguindo suportar, por exemplo, 100 milhões de acessos diários? Não, a gente não chegou a pensar nesse caso. A gente ainda iniciou uma conversa, mas a gente pensou que seria alguma coisa muito mais detalhada do que pedido para hoje, entendeu? Então, por exemplo, a gente chegou a pensar na questão de ter um CDN na frente do bucket. E aí a gente teria todas as informações aqui de vídeos e imagens para o Google, e a gente não precisaria sempre estar indo no mesmo bucket. O pessoal também chegou a falar de colocar um API Gateway e tal na frente dos serviços, mas a gente não chegou a destrinchar mais essas ideias. Show, show. Bom, qual que eu acho que o ponto principal aí de vocês que eu gostei? Vocês conseguiram seguir, basicamente, resolver os principais requisitos funcionais que o sistema estava pedindo. Eu acho que o ponto que faltou ainda, que faltou e, obviamente, é um ponto bem importante quando a gente está falando de sistema design, é a parte de conseguir fazer aqueles requisitos não funcionais entrarem em jogo. Por exemplo, você tem acesso a esse serviço. Esse serviço, ele consegue escalar? Como é que ele funciona? Você vai trabalhar com alguma... Eu vou dar um exemplo aqui simples. Vai na parte de feed ali para onde você colocou. Users, o último serviço. Maravilha. Você tem a acessar o feed, ali para onde você colocou, Users, o último serviço. Maravilha. Você tem a acessar o feed, você vai buscar todos os usuários que ele segue, vai pegar os posts desses usuários e vai retornar para montar o feed desse cara, certo? Sim. Se você perceber, basicamente isso é chamado de fan out on read. Basicamente é quando você tem uma lista de usuários, e daí para cada usuário você vai ter que consultar esse usuário, consultar os posts dele, e você vai ter que estar fazendo isso um a um, juntar tudo e trabalhar. Isso é chamado de fan out on read. O grande ponto desses tipos de situação é que isso, com alta volumetria, nenhum banco de dados do mundo vai aguentar, entendeu? Então, esses pontos que são, que acabam fazendo com que a gente pense em alternativas para que esse tipo de serviço ele consiga ser viável ao longo de muita escala. Nenhuma arquitetura acaba sendo imutável conforme a escala do sistema vai acontecendo. Então, nesse caso aqui, a mesma coisa. Para um sistema que acaba sendo pequeno, isso aqui vai atender. O sistema cresceu um pouco mais, só esse fanout on read que você tem, ele vai realmente fazer seu banco topar. Mesma coisa ali com as imagens. Por exemplo, se alguém colocar um vídeo muito grande para subir, como é que você vai subir esse vídeo no bucket da S3? Não sei se você já pensou assim. O cara tem um vídeo de 1GB como é que você manda 1GB direto pra um bucket talvez eu devesse quebrar esse vídeo em partes diferentes e salvar essas partes isso, ele pode ser um multi-part sim mesmo assim, existem algumas outras técnicas que a gente consegue fazer incluindo essa que você colocou de quebrar pra ajudar nesse processo. Entendeu? Mas, assim, gostei que vocês conseguiram resolver os pontos ali de requisitos funcionais. O que está faltando aí é o pensamento do design orientado agora aí para a alta escala. Show? Mas show de bola, Vinícius. Eu sei que o tempo é curto, é interessante que vocês conseguiram sentar, organizar, pensaram os endpoints. Achei interessante vocês terem pensado se é vídeo, se é imagem, se for um ou outro. Vocês colocaram um pouquinho aí uma regra de negócio. Eu, normalmente, em System Design, eu acabo deixando isso de lado, tá? Eu parto do princípio que um post é um post, e aí independente se é vídeo ou imagem, para tentar deixar um pouco mais simples, eu não tenho que ficar explicando regra de negócio no meu System Design, entendeu? Entendi. Quanto menos regra de negócio tiver, é mais fácil para todo mundo entender. Sacou? Então, essa aí é uma dica também que eu queria deixar para todo mundo. O System Design tem que tentar ao máximo ser auto-explicativo. Obviamente que a gente consegue fazer esses caras chegarem num nível muito hard. Esse do Instagram, o System Design deles, a mesma versão que eu vou mostrar pra vocês, ela é uma versão mais hard, mas ela dá pra ficar infinitamente, 10 milhões de vezes mais hard do que a minha. Eu consegui fazer uma pesquisa, conheço umas pessoas, inclusive, que trabalham e são ex-metas, então eu consegui alguns spoilers de como que esses caras hoje trabalham, como é que foi a evolução do Instagram. Então tem algumas coisas interessantes que depois eu posso comentar também. Me ajudou, inclusive, um pouco no meu system design na hora de fazer. Mas show de bola, Vinícius. inclusive um pouco no meu system design na hora de fazer. Mas show de bola, Vinícius. Valeu. Obrigado também. Show de bola, cara. Continua aí, continua aí, porque vamos ver o que o Sérgio tem para mostrar aí para a gente agora. Show. O Vinícius, se ele puder, é só descompartilhar dele, Vinícius? E aí, doutor Sérgio, quantas pessoas estavam no seu grupo? O meu grupo também tinha uns, acho que sete pessoas, eu consigo ver aqui. Um, dois, três, quatro pessoas, cinco. Show de bola. E os caras se deixaram na mão aí ou estão aí te dando uma força aí no chat? Como é que vai ser? Compartilha sua tela aí pra nós. Não, eles se fizeram juntos sim. Show de bola. Aí. Cara, antes de você sair mostrando, como é que foi a experiência? Como que vocês pensaram? Qual foi a linha de raciocínio que vocês fizeram? Imagino que são várias pessoas com backgrounds diferentes, então acho que essa pluralidade é bem bacana, conta aí a linha de raciocínio. É, a gente colou aqui as tarefas, aí o pessoal começou a escrever, a gente fez a API, eles começaram a editar também, aí as ideias foram surgindo. A gente começou pequenininho e foi aumentando ele, ampliando. Aí, fomos seguindo as tarefas para completar, né? E aí, opa, muda aqui, muda lá, e foi aumentando o sistema. Perfeito! Então, manda ver aí, cara., fala para mim as entidades que vocês encontraram aí. Nós pegamos as entidades usuário, o ID, nome e e-mail para ficar bem simples no começo, temos um user meta que vai ter o ID deste usuário e também o ID do other usuário, né? Esse aqui serve para pra gente conseguir os seguidos e seguidores. Primeiro e segundo, entre seguidos e seguidores. E também temos uma entidade do post, onde vai ter o ID e o conteúdo do post. Perfeito. Nós separamos também a API, né? Colocamos primeiro aqui tudo como post, o create, o upload imagem e o upload vídeo. Que na verdade vai ser um post com os endereços. Então vai ter um usuário, a gente colocou um CloudFront aqui por segurança, colocou um load balancer para ele escalar. A autenticação com a API Gateway. a autenticação com a API Gateway para... Aí colocamos o microserviço aqui de background, BFF, de backend para front. Então, dividido em duas linhas. Temos a escrita e a leitura. O salvar, ele vai ser responsável pelo create post. Então, a gente pode usar um sistema de fila, vai ter um create post. E o sistema de fila, vai ter um Create Post. O sistema de fila é lido pelo microserviço de salvar dados. O salvar dados vai criar o post no banco de dados, não relacionar o composto de conteúdo. Ao mesmo tempo ele vai disparar o upload de vídeo, que vai para o microserviço de upload de vídeo, que vai recortar esse vídeo em pequenos pedaços, gravar no sistema de bucket e a imagem pode ser convertida no próprio microserviço aqui e já vai direto, sem precisar recortar ela. E uma parte de leitura. Vamos lá, cara. Vamos fazer o seguinte, Sérgio. Tenta fazer o seguinte. Tenta me explicar e me passar por esse system design Baseado nos endpoints que vocês têm Porque daí é fácil a gente matar Aqueles requisitos Então o que você mostrou agora pra mim Foi o CreatePost, certo? Isso, o CreatePost O CreatePost Ele vai Vai ser a chamada do usuário Vai ter o post, vai ter o vídeo dele com os dados, e a gente vai realizar a criação do post, o upload de vídeo, o vídeo vai cair lá no microserviço de upload. E a imagem também, aqui teria que ser, na verdade, ele ser mais dividido, né? Não deu tempo para a gente discutir muito essa parte. Assim que eu tiver o Create Post, né? Também o microserviço vai dar o retorno que ele conseguiu fazer o upload, vai conseguir recortar os pedaços do vídeo, conseguiu salvar, né? E vai ter que ter um retorno aqui para o nosso tópico e o upload também a partir de eu ter os três aqui no meu tópico satisfeitos é que eu realmente tenho um create post e eu vou ter um micro serviço de feed que vai ler depois esse banco de dados e vai ler também o vídeo. E esse serviço de feed vai montar um perfil no nosso usuário, como uma espécie de cache. A gente colocou Redis aqui, porque a gente lembrou na hora, mas poderia ser outro serviço e tal. Ele vai ter um cache para que cada requisição que a gente vai de consulta do feed não tenha que gerar todo o perfil do usuário, porque a gente não tem um sistema acaba não aguentando isso, então a gente vai usar cache, o perfil vai estar montado, inclusive com os seguidores e não seguidores, então a gente vai ter um cache e não realmente uma montagem de relações. Ah, vou saber qual vídeo é de qual, qual a storage é de qual, para daí eu montar e para daí entregar para o usuário. Vai estar montado já o perfil. Então, esse seria o caminho da leitura. Essa leitura que você está me dizendo é a visualização do feed do cara, é basicamente isso, né? Exatamente. Aqui faltava também, a gente acabou apagando, mas também tem o follow user e unfollow, né? Esse aqui poderia ser mais direto, porque o follow user e unfollow, ele é apenas talvez um put lá, você manda seguir o usuário, ele acaba caindo no user meta dele aqui, que depois o serviço de feed vai conseguir identificar de onde ele vai montar o perfil do usuário. Show! Posso começar com algumas tricky questions aí pra vocês? Claro, claro. Vamos lá. Cara, me explica um pouco mais como que você gera esse feed. Qual que é a ideia, como é que porque por exemplo, da forma que você tá colocando, imagina que eu sou a Taylor Swift sou o Neymar ele tem não sei quantos milhões de seguidores exatamente a gente pensou nisso também e a gente levou um pouco em consideração a história do Twitter, que o Twitter no começo ele fez a relação e depois ele deixou de lado a relação jogando todo mundo em banco não relacional. Hoje em dia nem tem muito os seguidores, você vê posts de outras pessoas. Então teria que ter um limite aqui no feed, você veria os últimos 20 posts dos seus seguidores. Então você ainda tem que ter um outro sistema que vai elencar quais posts vão mostrar, quais posts não vão, né? Hoje as redes sociais, o Instagram estava em 5%, hoje não está mais. Mas você vai ter que... Mas vamos pensar num ponto um pouquinho mais técnico. Ah, tá. Entendi. Vamos pensar um pouco mais técnico. Vou imaginar. Eu sou o Neymar. Entendi. E eu sigo pessoas com 10 seguidores. Eu sou o Neymar e eu sigo o Sérgio, que tem 10 seguidores. Quando eu, Neymar, ver o meu feed, em tese, eu tenho que ver os últimos posts dos meus seguidores. Agora, eu tenho o lado ao contrário. Eu sou Wesley e eu sigo o Neymar. E eu sigo o Neymar, eu sigo a Taylor Swift, eu sigo um monte de gente famosa e daí na hora que eu acesso o meu feed, eu quero ver os posts desses caras aí pra mim. Como é que funciona o caminho até o banco de dados? Então, seria o consultar aqui. E esse microserviço aqui teria que achar o seu feed já montado com os últimos posts, entendeu? Meu feed montado? Mas espera um pouquinho, vamos pensar o seguinte. Se o meu feed está montado e eu sigo o Neymar, significa que toda vez que o Neymar fizer um post, eu vou ter que adicionar o post dele no meu feed? Isso aí. E daí, se o Neymar tem 20 milhões de seguidores, ele postou uma coisa, eu vou enfiar no feed dele 20 milhões de posts dentro do feed das pessoas? É, na verdade no perfil dele vai ter apenas um post. Não, não, não, eu estou pensando assim, eu estou pensando no ponto ao contrário. Eu sigo o Neymar. Você segue o Neymar. Exatamente. Eu entendi. Aqui, no post ID, no banco de dados do Neymar, no perfil dele, vai ter apenas um post. Porém, eles são 20 milhões de pessoas. Eu teria que replicar esse post dele em 20 milhões de pessoas. É isso que você está dizendo. Só que, neste caso, a plataforma não vai fazer isso, entendeu? Eu tenho mais disponibilidade do que consistência. Por quê? Porque seria impossível gerar isso daí. As outras redes não fazem isso. Claro que há uma maneira de fazer. Mas, imagine também eu consultar e fazer toda a consulta pra pegar esses posts e distribuir pras pessoas, não né então eu vou ter que ter toda uma política de saber qual post vamos imaginar o seguinte desculpa te cortar Sérgio, vamos imaginar o seguinte a nossa regra é clara eu sigo alguém, eu quero ver os posts dela pessoa, se 10 pessoas seguem o Neymar essas 10 pessoas tem que quero ver os posts dela pessoa. Se 10 pessoas seguem o Neymar, essas 10 pessoas têm que poder ver os posts do Neymar. Então, esquece essas políticas. Pensa tecnicamente. Como que eu faço pra que as 20 milhões de pessoas que sigam o Neymar, quando ele postar um post, essas 20 milhões de pessoas vão conseguir ver esse post no feed delas. Entendi. É tricky, né? É, eu sei. Não é fácil, não. É, aí a gente teria que bolar uma nova coisa aqui. Mas a sua ideia principal aqui, pelo que eu estou entendendo, é, você está querendo pré-construir o feed. Isso. Mas de quem? Você está querendo dizer o seguinte, se eu vou ver o Neymar, eu vejo o perfil do Neymar pré-construído, porque daí ele está cacheado, resolve para caramba a minha vida. Eu acho que essa pré-construção fantástica, genial, funciona bem para caramba, inclusive é o que você falou, Twitter e muitas ferramentas usam isso, porque não faz sentido ficar fazendo uma consulta toda hora. Eu acho que o maior desafio, inclusive no caso do Instagram e nesse system design, é como o meu feed funciona. Ou seja, eu como usuário tenho que ver os posts de todo mundo que eu sigo. Exatamente. Ou seja, como que é feita essa lógica. Eu acho que é esse ponto aí que eu quero que você depois dê uma pensada, antes inclusive, de eu mostrar a minha solução, não estou dizendo que é a melhor do mundo, mas é uma solução meio que padrão para esses tipos de problema, tá? Mas dê uma dá mais ou menos, dá uma pensada em cima disso. Uma outra pergunta que eu queria fazer aqui para vocês é por que que ali você escolheu o banco de dados não relacional e quando você fala em não relacional, qual seria esse banco de dados não relacional? Poderia ser qualquer um que grave em JSON, porque eu vou descarregar dados, né? Vai ser uma gravação, uma gravação rápida. Como eu tô lidando com posts aqui do mundo inteiro, e os posts, eles são criados muito mais do que o número de perfis, então eu escolhi o relacional, porque ele grava mais rápido, eu posso ler mais rápido também, é a performance, eu escolhi pela performance. Uma pergunta, desculpa te cortar, vamos lá, você está me dizendo que a performance de gravação de um banco de dados não relacional é mais rápida do que a de um relacional? Sim, provavelmente sim, porque eu não tenho a relação, não preciso checar campos para saber se o ID é inconsistente ou não, se eu estou gravando ou não. Eu acho que é só o texto ali que ficou como não, talvez seria não relacional no texto ali da caixinha. Ah, aqui. Você está falando? Não, não, não. Eu estou olhando do lado do Create Post mesmo. Porque eu tenho minhas dúvidas. Se criar um post num banco de dados relacional é mais lento do que criar num não relacional. Por exemplo, se eu botar um MongoDB e um Postgres, ou se eu botar um MongoDB e um Postgres, ou se eu botar um... Apesar que o DynamoDB é não relacional de coluna larga. É que você está focando muito mais em documento. Então, aí a gente vai para uma categoria mais do Mongo. Ou até mesmo Cassandra, né? Exatamente. Aqui eu não tenho muita preocupação. Aqui também eu vou ter que colocar aqui no relacional O ID do vídeo e o ID Da imagem que tem Perfeito Como eu não tenho outras tabelas Aqui não tem problema Até o relacional poderia, vai gravar ao mesmo tempo Acho que não tem problema não Não seria documento Seria até menos espaço Show Wesley É só uma escolha de pensar Não seria documento, entendeu? Seria até menos espaço. Show. Wesley. Não tem um... Só foi uma escolha, assim, de pensar, tipo, não, vamos descarregar os dados lá. É que hoje em dia, por exemplo, assim, você pega uma empresa muito grande, ela já nem usa isso daqui, né? Ela vai passar por um serviço e jogar isso aqui em JSON no S3. Vai ser tudo S3. E aí vai ter um serviço que vai transformar S3 em algo pesquisável, tipo um Apache que coloca lá pra aí você poder usar o SQL. Vai ser tudo diretório, eu tô dizendo, né? Tá, uma pergunta básica aí é se esse vídeo aí tivesse 1 giga, como é que é feito o upload desse cara? Você tá mandando aí pra um blob storage com S3, como é que é feito o upload desse cara? Você está mandando aí para um Blob Storage, um S3, como é que funciona esse upload? Isso, aqui no microserviço que eu criei, nesse microserviço ele vai ser um microserviço que vai dividir esse vídeo, sei lá, usando um FFmpeg, ele vai ter que recortar esse vídeo e gravar os pedacinhos lá em TS no Blob Storage aqui, né? Tá, mas pra ele gravar, porque é o seguinte, vamos lá. Uma coisa, eu tenho vídeo cru, certo? Isso. Aqui, esse vídeo cru, ele, pra que esse microserviço de, esse vídeo cru tem que subir primeiro no S3 antes de você gravar nos pedacinhos, certo? É verdade, sim, sim. Ele tem que subir primeiro. Ele tem que subir primeiro no S3 antes de você gravar nos pedacinhos, certo? É verdade, sim, sim. Ele tem que subir primeiro. Como que você faz essa subida? Você tem alguma ideia de... Ou é um upload padrão usando o S3 mesmo e tá com... Isso. Nós pensamos assim. Não pensamos em nada ainda um upload diferente. Era gravar ele direto e depois recortar ele, porque para o acesso vai ser melhor, entendeu? Show! Cara, gostei bastante do quê? De vocês pensarem que vocês estão trabalhando de forma assíncrona, então isso ia ajudar a garantir um pouco mais de de escalabilidade, de confiabilidade. de... de... de... Escalabilidade. É, um pouco a base de escalabilidade. Exatamente. Gostei também de vocês conseguirem pensar nessa história do feed, apesar de eu ter percebido que vocês pensaram ao contrário. Vocês pensaram muito mais a pessoa ver o perfil dela e não de como ver o perfil dela e não de como que o perfil dela consegue ver eu vendo os feeds meus que são gerados das pessoas que eu sigo. Achei interessante separar uma parte de leitura, uma parte de escrita. É, seria interessante que você teria um orcs assíncrono pra preenchimento de cash aí você conseguiria a estratégia do fanout que foi pedido ali em uma das atividades na verdade é que era pra gerar o feed não o perfil da pessoa o lance do feed a gente tem aquele problema de o problema do Neymar o problema da Taylor Swift. Mas show de bola, cara. Deu pra pegar a ideia. Vou dar uma dica aí pra você. Não só pra você, mas pra todo mundo que tá assistindo. Cara, sobe um pouquinho mais ali nas suas entidades, na parada toda ali. Sobe ali um pouquinho mais. Eu não sei se vocês perceberam. Você viu parada toda ali, sobe ali um pouquinho mais. Eu não sei se vocês perceberam, você viu que você colocou follow user e unfollow user? Isso. Perceba que nos requisitos funcionais não tinha pra não seguir um usuário. Ah, é verdade. É só seguir outros usuários. Perceba também que ali eu não tô tão preocupado com post se é imagem, se é vídeo e etc. Saca? É basicamente fazer uma publicação, é fazer um post. Então, a única dica que eu tento dar aí para vocês é o seguinte, se você cria um endpoint, esse endpoint vai ter que estar presente no seu System Design, entendeu? Então, por exemplo, você colocou follow user, esse endpoint não está no seu System Design. Entendeu? Então, por exemplo, você colocou Follow User, esse endpoint não está no seu System Design. Entendeu? Não, os dois não estão. Nem o Follow, nem o Follow. Exatamente. E ele é um dos requisitos funcionais, entendeu? Sim, sim. E como é um requisito funcional, ele tinha que estar nesse System Design. Então... A gente acabou apagando ele daqui, aqui, aí vai, não vai dar tempo, tirou. Não, beleza. Mas vocês pegaram a ideia, né? Sempre, o que tem que estar nos seus requisitos funcionais, tem que estar no design. Se não tá no requisito funcional, tipo unfollow o cara, não coloca. Porque é mais um, é mais serviço, é mais, cara, pra desseguir uma pessoa, é mega complexo, aparentemente, no Instagram. Não seguir uma pessoa, você vai ter que tirar ela do seu feed, ela vai ter que mudar um monte de banco de dados. Então, quanto menos você colocar, é mais. Outra coisa, por exemplo, você colocou ali observabilidade, cara, tipo, arranca tudo fora essas coisas, entendeu? observabilidade, Dynatrace, cara, tipo arranca tudo fora essas coisas entendeu? Porque não foi pedido e mesmo que não tivesse, você colocou você tá abrindo margem aqui pra mim, eu vou falar cara, qual que é a diferença do Datadog pro Dynatrace? Entendi o que um entende melhor? Você abriu uma cortina pra alguém sair indo muito em cima da coisa observabil a observabilidade, tá? E aí, onde você usa o Open Telemetry? Como é que você está com o tracing? Como é que você está fazendo o tracing nesse Kafka aqui, entendeu? Entendi. Você abre uma porteira de perguntas que, às vezes, você não está esperando. Então, sem System Design, você tem que colocar o mínimo possível, mas o suficiente possível para que você cumpra os requisitos não funcionais. Fechou? Fechou, muito obrigado. Show de bola aí, grande Sérgio, cara. Valeu pelo trampo, cara. Vocês fizeram bastante coisa aí também em pouco tempo, cara. Curti bastante aí o que vocês fizeram, cara. Show de bola. Muito obrigado. Maravilha. Cara, dá tempo pra gente fazer com mais uma pessoa antes de eu colocar. Temos o Guilherme. Guilherme, mas você tem que ter câmera, cara. Pô, Zé, minha câmera tá zoada que eu não consigo abrir, cara. Será que você não abre uma exceção pra mim, não? Vai depender do chat. Eu não vou tomar essa decisão. Galera, abre pra esse cara aí sem câmera, sem a gente ver a cara bonita dele. Qualquer coisa eu compartilho, alguém do meu grupo pode ir explicando aí também. Ó, a galera falou, ó, tem gente falando não, tem gente falando que sim, tem gente falando próximo, a regra é clara. Bora, Guilherme, mostra essa parada aí, cara, vamos lá, vai. Não é... Hoje eu tô muito feliz, então... Quando você estiver vendo aí, vocês dão um toque aí. Show de bola. Aqui a gente... Aí os fãs da AWS gritam nesse momento, né? É, aqui a gente tentou não atrelar tanto, né? Mas como a maioria do time, ele tinha experiência com a AWS, a gente acabou indo, utilizando os produtos ali da AWS, né? Basicamente, a gente teve uma discussão, né? A gente quebrou ali por entidades, depois a gente quebrou por tabela, né? Pra ali chegar no endpoint e só assim, então, começar a fazer o desenho, tá? Então... Quais são as entidades de vocês aí? As entidades que a gente criou foi o usuário, né? O post e o follow, né? Que é pra fazer a amarração ali dos seguidores, né? E os endpoints? Isso, os endpoints são o post para criar um post, um endpoint para poder seguir e um get para poder trazer as publicações no feed. São esses três endpoints que a gente conseguiu criar. O primeiro desenho, essa primeira parte aqui, está representando a criação de um post, né? Então a gente colocou aqui um gateway aqui na frente, né? Aí a gente colocou um cluster aqui, um EKS, para poder escalar ali a nossa aplicação. E aqui a gente usou um fanout, né? Poderia ser um Kafka, aqui a gente está usando o SNS com o SQS, mas poderia ser um Kafka ou outro serviço de mensageria. E a gente colocou um consumer aqui para ficar assíncrono. Então, por exemplo, o usuário vai criar uma publicação, mas ele não vai ficar aguardando aquilo ser postado. Ele vai receber ali um 200 e aí um serviço em segundo plano vai catar aquela publicação do tópico e vai fazer aqui, vai colocar no banco e a gente criou um Redis aqui para poder diminuir o tráfego no banco aqui. Então a gente vai criar também essa publicação no Redis para depois no Get conseguir consultar ela. Então essa daqui ficou o desenho da criação de uma publicação. Tá, e a imagem, o vídeo, essas coisas? Vai ser tudo por aqui, a gente vai colocar, aqui não deu tempo de colocar aqui, mas quando for um arquivo, a gente vai colocar no S3, né? Porque ele tem umas configurações ali de alta disponibilidade e tal, então a gente optou por usar ele. Belezaza Tanto é que no get aqui a gente acabou colocando Pode ver que no endpoint de get Ele bate tanto no banco No redis e no S3 aqui Perfeito Beleza Esse segundo desenho aqui Ele é o de seguir Então ele ficou bem parecido Com o de criar uma publicação Porém a gente não precisa do S3 e nem do Redis, né? A gente só vai postar lá no tópico mesmo, e aí o consumer vai pegar e vai fazer as amarrações necessárias aqui no banco de dados, tá bom? E por último, o endpoint de obter o feed ali, né? Então a gente vai bater ali num banco, né? Por conta da volumetria talvez aqui seria um cluster e tal. O Redis, né? E o S3 aqui. Aí ele vai juntar as informações pra poder mostrar ali no feed do usuário, né? Então, foi esses três desenhos que a gente conseguiu fazer dos três endpoints. Show de bola. Ah, cara, eu vou fazer algumas perguntas para você, mas eu quero fazer um comentário importante aqui. O Paulo colocou aqui o seguinte. Quantas pessoas aqui trabalham com sistemas com a quantidade na casa de milhões de usuários ativos? Infelizmente, poucos arquitetos terão a oportunidade de desenvolver sistemas nesse nível de complexidade. Ou seja, estamos aprendendo algo que dificilmente vamos precisar aplicar e que em muitos casos somente tratará a complexidade desnecessária. Vamos lá, Paulo, cara, seguinte, eu concordo com o que você fala e discordo ao mesmo tempo, tá? Com certeza não vai ser todo mundo aqui que vai trabalhar com um sistema de escala de milhões. Mas muito, mas muito do que a gente está aprendendo aqui, colocando aqui, você não precisa ter milhões de usuários para você conseguir fazer um system design, para você fazer o sistema da sua empresa escalar, para você fazer o sistema que você está trabalhando no banco onde você trabalha, escalar para você trabalhar em qualquer empresa que no final das contas utilize microserviços, componentes se conectando, tá? A questão aqui é, a gente coloca um Instagram com milhões, principalmente porque todo mundo conhece como é que funciona um Instagram. Eu não iria colocar aqui um sistema bancário que nem eu conheço o domínio. Mas entenda, a arquitetura de solução não é algo feito somente para milhões de usuários. Muito do que vocês vão aprender aqui, vocês vão começar a perceber que você vai entender sobre disponibilidade, você vai entender sobre segurança, sobre distribuição de conteúdo global, como é que funciona a parte de fan-out, fan-out on read, fan-out on write, estratégias de como que você trabalha com cash e invalidação de cash, utilizações de bancos de dados. Tudo isso é independente de ser milhões. Então, a gente tem que tomar cuidado para a gente não ir no 880. Ou eu aprendo algo para milhões que eu nunca vou trabalhar, ou tudo o resto é complexidade desnecessária. Não existe o meio termo. Nas empresas que... A maioria das empresas que os nossos alunos, que diversas pessoas profissionais que eu conheço, tem problemas extremamente similares, não são milhões, mas são milhares, já é o suficiente pra você precisar de ter uma arquitetura mais robusta daqui pra frente, o mais importante vai ser a gente conseguir entender esses tipos de arquitetura não para aumentar a complexidade, muito pelo contrário, para diminuir a complexidade. Porque complexo seria você conseguir fazer tudo isso usando, sei lá, um único banco de dados ou sem nenhuma estratégia de cache ou sem ter um API gateway na frente. Isso sim seria complexo, tá? Então, vamos tentar tomar aquele cuidado, galera, de não pensar, ah, é porque é Instagram, eu não tenho que aprender aquela arquitetura. Não, você não precisa aprender como é a arquitetura do Instagram. Mas tem fundamentos aí que vão servir para diversas e diversas situações nas empresas onde vocês estão, tá? E outra coisa, né? Quem disse que ninguém aqui pode um dia trabalhar na Meta, no Google, no Instagram e tal? Talvez, muitas das pessoas que estão aqui que não trabalham nessas Big Techs, exatamente porque não aprenderam isso. Porque se você for tentar entrar, você vai cair num sistema de System Design e se você não souber, provavelmente você vai bombar na bombar na prova, tá? Mas, de forma geral, o meu ponto aqui não é de longe de ser pessoal pro nosso colega que comentou, porque eu entendo muito a dor do que ele falou e concordo com ele, mas a gente tem que conseguir ponderar, galera, não é 880, ou eu tô desenvolvendo o Google Search, ou eu tô fazendo o sistema da padaria, acredite, se você trabalha num banco, se você trabalha numa empresa de varejo, se você trabalha em diversos ramos de indústria, tá? Esses tipos de arquitetura nos dias de hoje são coisas muito comuns. É importante vocês aprenderem. Beleza? Então, eu acho que o mais difícil hoje em dia é fazer o simples que é complexo ficar mais simples, tá? Desculpe cortar o raciocínio, meu amigo. Imagina. Vamos seguir. Eu peguei a ideia sua aqui, mas eu quero complementar aqui um pouquinho com o que eu falei com o nosso amigo Sérgio agora há pouco. Eu entendi muito que você grudou componentes, mas eu senti um pouco de falta de inteligência. Pelo amor de Deus, eu não estou dizendo que você não tem inteligência faltou um pouco de inteligência de como funcionam esses componentes por exemplo, você colocou ali que vai usar o Redis, né? como que funcionaria o Redis aí nesse caso para o cache, por exemplo, para mostrar o feed a gente não entrou tanto no detalhe da implantação, mas a ideia era armazenar aqui os posts e ir atualizando para a gente não precisar, na hora de buscar, bater no banco, entendeu? Tipo, ter um determinado período e buscar os caras que estão aqui. Entendeu? Peguei, peguei. Talvez talvez pensando agora com você, talvez não entendi o que você quis dizer. Porque na hora de recuperar não vai fazer tanto sentido, né? Não, na realidade faz todo sentido. Um sistema desse não consegue rodar sem cache, com certeza. O maior ponto aí é que quando a gente vai em cache, a gente começa a entrar aí numa seara que ela consegue ficar mega complexa e essa complexidade aí, de forma geral, é necessário a gente entender um pouco para esse tipo de design. Mas eu peguei a ideia, você seguiu bem os pontos componentes, estou matando os requisitos funcionais. A única coisa que é o seguinte, você colocou uma forma que escala, vamos dizer assim com componentes da AWS mas esses componentes eles não estão explicativos ao ponto de entender de como que funciona essa lógica a amarração dessas pontas, entendeu? o que eu acho que está faltando é um pouco disso, a amarração dessas pontas, mas cara, show de bola, é pouco tempo, é importante que vocês pararam, sentaram, pensaram e show de bola. É interessante que como cada system design vai complementando um pouco o outro que a gente viu aqui a pouco. Wesley, quando você fala que você não entendeu a lógica de como... Eu não entendi muito bem. Você fala, por exemplo, como que é esse consumer estar ligado ao... Não, não, por exemplo assim, você vai mostrar o feed pra mim, tá? Como que esse cache vai ser gerado no feed? A gente não chegou tanto nesse detalhe, sabe? É nessa questão do cache, Wesley, a gente pensou mais, tipo assim, quando eu entro no meu feed hoje eu quero que os dados mais quentes ali entre as, os dados mais atualizados apareçam pra mim, então a gente pensou em utilizar esse cache aí com TTL, sei lá tipo de um dia mais ou menos, pra trazer esses dados mais atualizados pra aliviar essa pressão do banco de dados perfeito, mas eu sou o Wesley, eu estou seguindo o Cristiano Ronaldo eu estou seguindo o Messi, o Neymar a Taylor Swift, a Lady Gaga que fechou agora e ela postou, eu quero ver no meu feed como é que eu acesso esse cache pra pegar o post da Lady Gaga pra eu que sou seguidor dela e pra você que é seguidor dela sacou a parte que é seguidor dela. Sacou a parte que é mais... Entendi, na hora de buscar que foi o mesmo problema, né? Sacou? O tamanho de uso de PubSub não seria suficiente? Como é que é? Fazer um PubSub. Cara, mas PubSub aonde? Porque imagina, eu tenho 100 milhões de usuários Eu A Taylor Swift Com 20 milhões, nem sei, ela deve ter mais Fez um post O Neymar fez um post O seu amigo Que tem 10 seguidores fez um post E todos esses posts, quando acessar meu feed Tem que aparecer pra mim em menos de 400 milissegundos Como é que eu faço essa busca? Eu acredito que esse... Desculpa, acho que eu interrompi ele a responder. Pode falar. Pode falar, Rafael, desculpa. Eu percebo da seguinte maneira. Não, eu estou pensando. No momento em que a postagem é feita, o sistema de mensageiria notifica o Orkis que, assim como a mente, ele faz a atualização do cache. E isso, considerando que, como a gente está falando de celebridades, tem que existir um pré-cálculo do feed para identificar essas pessoas. Então, está criando aí o movimento de tá gravando pra todos os seguidores, né? Então isso eu queria que ocorresse dinamicamente. Bom, entendi a linha de raciocínio, mas show de bola. Galera, eu acho que a gente conseguiu trazer bastante discussão, eu acho que eu consegui pegar os pontos que vocês fizeram e eu vou compartilhar um pouco como que eu fiz como eu acho, e obviamente né galera vocês tiveram 40 e poucos minutos eu tive o dia inteiro de hoje pra montar o meu pesquisar e conversar com pessoas que eu conheço, tá? E fora que eu tô bem acostumado a fazer System Design, a gente tem o nosso MBA direto, a gente tem aulas de System Design, então, obviamente, eu tô com, provavelmente eu faço mais System Design do que vocês no dia a dia, eu acabo pegando um pouco mais prática, isso não significa que eu sou o fodão, nada disso, é simplesmente uma questão de tá ali mexendo com aquela parada no dia a dia tá, eu vou fazer o seguinte tá, eu não quero, obviamente ficar desenhando detalhezinho na tela aqui pra vocês verem eu tomando um pau com setinha apontando, mas eu tenho isso um pouco pronto, mas eu não vou trazer tudo de uma vez, porque senão ninguém vai entender nada, nenhuma linha de raciocínio. Então eu vou tentar seguir a mesma cadência que vocês estão fazendo. Entidade, endpoints, e a gente vai construindo a solução de uma forma simples e depois a gente vai tentando bater os requisitos não funcionais. Fechou? Então vamos lá, deixa eu compartilhar aqui a minha tela para que nós possamos mexer nessa parada. Show de bola. Deixa eu compartilhar uma parada aqui para ninguém mexer na minha tela. Deixa eu puxar o chat para eu conseguir ver o chat aqui, porque eu gosto de ver o que a galera tá escrevendo. E também vou a carinha da galera aqui também pra eu ver a cara bonita do povo aqui. Bom, vocês estão vendo a minha tela, né? Sim. Show de bola. Então é o seguinte, galera, a gente tem três requisitos funcionais. O usuário pode criar post com a possibilidade de fazer upload de imagens e vídeos legal, então a primeira coisa pra mim que tá claro é que quando eu tô pensando em entidade, normalmente eu penso principalmente nos substantivos dos caras aqui então eu tenho, eu tô falando de usuário e aqui eu tô falando de post tá, e depois eu estou falando de post. E depois eu tenho a parte de mídia, que provavelmente é onde eu estou falando de imagens e vídeos. E upload é uma ação, mas eu estou... Deixa eu colocar imagens e vídeos aqui. Legal? Então, quando eu estou pensando aqui de cara, para mim, eu já consigo mapear alguns caras interessantes aqui para mim. Um, entidade, eu sei que eu tenho provavelmente aqui um user. Então, acho que isso aqui, eu acho que todo mundo chegou na mesma conclusão. Fora isso, eu tenho provavelmente posts. Certo? Eu tenho um post que eu vou ter que criar. Provavelmente, eu vou ter também uma parte ali de mídia, onde eu tenho os dados que eu vou ter que subir. Tem uma entidade que eu não tinha colocado originalmente no meu, mas quando eu vi um dos systems designers, eu não sei se foi o do Sérgio, eu não me recordo de quem fez, e eu acho que isso pode ser considerado uma entidade sim, apesar que inicialmente eu não tava considerando ela, tá? Mas eu acho que pode ser considerado uma entidade. Que é, vamos dizer aqui, como que o, eu não sei se foi o Sérgio, eu não lembro quem que foi, colocou isso como follow tá, porque basicamente é a junção de um usuário que tá seguindo o outro, tá então é mais ou menos essa mais ou menos essa pegada aqui, tá, então o que que acontece é o seguinte uma vez que eu tenho essas entidades eu vou pensar nos como que eu tenho essas entidades, eu vou pensar nos... Como que eu modelo essas informações. E, galera, uma coisa importante quando a gente está fazendo System Design, principalmente se você está fazendo entrevista, tá? Essas coisas, elas têm que ser feitas de forma bem rápida. E você não tem que gastar muito tempo pensando, inclusive, em detalhes do tipo Ah, isso é inteiro. Isso é é string isso é não sei o que galera relaxem com esse tipo de coisa tá então isso aí é um ponto importante quando eu tô falando aqui em data modeling no final das contas eu vou pensar a primeira coisa isso aqui eu vou pra não ficar gastando meu a minha expertise que eu tenho em Scaledraw, eu vou tentar colar essa parada aqui e ver se vai. Tá? Primeira coisa que eu vou pensar aqui é numa tabela e aqui eu não tô preocupado se é banco de dados relacional ou não relacional. Por exemplo, o que eu posso dizer aqui com mais certeza é que eu tenho um ID, que é uma primary key, que vai identificar esse cara como único. Eu tenho um user ID, eu estou colocando esse cara como um índice aqui na minha frente. Sempre quando vocês forem falar de system design e começarem a me perguntar em modelagem de banco como que eu consigo explicitamente conseguir melhorar a minha performance, então o índice pode parecer uma coisa boba, mas explicitar isso é algo extremamente importante. Uma outra coisa que eu tenho aqui é S3 URL, ou seja, vai ser a URL que está armazenada a mídia daquele post, porque se eu for subir esses dados, provavelmente num S3, num object storage, provavelmente o que vai acontecer, eu vou ter uma URL para esse cara aqui também. Aí eu coloquei somente algumas informações ali bem simples, de title, description, mas essa parte de status e created at, elas são importantes e depois a gente vai falar um pouquinho mais sobre isso tá? Um outro cara, pra mim que é importante tá? Uma outra tabela e eu tô falando muito de tabela aqui galera porque eu posso, por exemplo escolher aqui nesse caso, tá? que são dois casos de uso aqui muito claros eu vou tirar esses índices aqui por enquanto, porque a gente vai falar disso um pouquinho depois. Eu posso ter tanto uma tabela, ou pode ser uma tabela de um banco de dados relacional, um Postgres, por exemplo, ou pode ser uma tabela, por exemplo, do Cassandra, pode ser uma tabela do DynamoDB, por exemplo, que são bancos de dados que cabem bastante aí nesse caso aqui para a gente. Então, o que isso significa aqui, galera? Essa tabela, basicamente, eu tenho o cara que é o seguidor, ou seja, o cara que segue para o cara que está sendo seguido. Ou seja, eu tenho o Wesley seguindo o Neymar. Basicamente, é isso que eu tenho, e eu vou ter esses caras. Com isso aqui, eu já consigo ter mais ou menos clareza de como que os dados e essas informações acabam trabalhando aqui com a gente. Então, nesse tipo de coisa, eu posso ter os meus dados, os meus usuários, posso ter os meus posts. Aqui, em relação à minha URL, eu posso ter diversos tipos de mídia. Pode ser um vídeo, pode ser uma imagem. Se eu for ter, sei lá, um carrossel, por exemplo, eu posso ter aqui, no final das contas, uma lista com diversas imagens, etc. O grande ponto aqui que eu quero tentar trazer aqui pra vocês é quais dados que fazem parte da informação ou do pedaço desse requisito funcional. Eu não vou nem ficar gastando tempo aqui, galera, em criar uma tabela de users que tem nome, que tem e-mail. Galera, se a gente tá falando em System Design, a gente não precisa, às vezes, ficar colocando coisas que parecem um pouco óbvias, tá? Então, o id é string. Ah, o user, eu vou ter que colocar o username e etc. Eu posso até colocar aqui, mas o ponto depende muito pra onde que eu tô querendo atacar e o tipo de complexidade que eu tô querendo mostrar, tá? Então, isso aí é importante aí pra gente conseguir se ligar. Maravilha? Esses caras aqui, a gente vai falar, porque dependendo do banco de dados, a indexação desse cara muda, mas eu quero falar um pouquinho disso aqui com vocês daqui a pouco. Fechou? Agora, o lance é o seguinte. Nós temos que cumprir esses requisitos funcionais, certo? Ou seja, criar novo post, fazendo upload, eu posso seguir um usuário, o usuário terá acesso ao feed com o post dos usuários que ele está seguindo. Basicamente, esses são os requisitos funcionais. Para isso, eu tenho aqui o meu API design então nesse caso aqui eu estou muito parecido com o que vocês criaram até agora, tem algumas diferenças mas de forma geral a gente, eu acredito que está ralazoavelmente bem alinhado e eu acho que não é nenhuma surpresa aqui, tá? que é basicamente essa pegada eu tenho um post onde eu vou seguir, né? subir o meu novo aqui, tá? Que é basicamente essa pegada. Eu tenho um post onde eu vou seguir, né? Subir o meu novo post, tá? Eu vou ter o nome, a description, o title, da forma como a gente queira trabalhar, né? Status. O status aqui, galera, eu coloquei apenas pra gente ter em mente, tá? Quais são os possíveis status que existem dentro de uma regra que a gente pode querer trabalhar. Então, poderia ter um status como publicado, se ele está fazendo upload, se ele está convertendo. Isso aqui é até importante na realidade, até aqui para não gerar confusão. É para ficar mais claro cada parte, para não ficar gerando esse tipo de dúvida. E aqui tem a parte de mídia data. E por que eu estou colocando mídia data aqui? Porque essa parte aqui, especificamente, ela é um pouco tricky. Porque a gente tem situações, como que eu mando um giga para um S3 ou como que eu mando um giga para um micro serviço para ele subir em algum lugar ou guardar essas informações então, de cara aqui no meu post eu estou colocando o name, description, status e eu coloquei um asterisco aqui porque a gente vai ter que trabalhar de uma forma um pouco mais criativa e que é bem padrão de mercado na realidade. Uma outra coisa que é interessante sempre falar, tá? É o seguinte, toda vez que vocês estiverem fazendo System Design, colocando pontos aqui de usuário final, você sempre vai partir do princípio que esse cara, ele está, como se diz, autenticado no sistema. Então, eu não preciso colocar post barra ID do Wesley, ou quem é o meu ID. Eu posso partir do princípio que todos esses caras aqui, ele pode ter um header com um token JWT que informa quem sou eu. No final das contas, é meio que isso que acontece no dia a dia. Então, eu não estou muito preocupado de falar que eu, usuário, estou postando, tá? Então, a ideia principal é eu conseguir criar um novo post, é um endpoint aqui pra mim. Um outro cara que eu tenho aqui é o users barra follow, né? Ou seja, eu quero seguir um usuário e eu vou seguir o usuário que eu vou querer seguir, né? Então, eu posso até colocar aqui o user que eu quero seguir, né? Então eu posso até colocar aqui o user que eu quero seguir, né? Partindo do princípio que eu tenho o meu JWT identificando quem sou eu. E aqui, por último, tá? A gente tem aqui o nosso feed, né? Onde eu posso pegar o feed do meu usuário e mostrar aqui pra mim uma lista de posts. Tá? Então é basicamente isso que eu acabo tendo usuário e mostrar aqui pra mim uma lista de posts. Então, é basicamente isso que eu acabo tendo no meu feed. Então, basicamente, com isso, eu cumpro aqueles meus três requisitos funcionais. Eu consigo criar um novo post, eu consigo seguir alguém e eu consigo listar aqui o feed, né, de... o feed ali do meu Instagram e trazendo aqui pra mim uma lista simples de post e tudo mais então, galera tamo de boas aqui eu acho que isso aqui não é um segredo maior e etc eu acho que o maior ponto é quando a gente começa a entrar aqui no system design em si, né, deixa eu até apagar aqui que a gente começa a entrar aqui no System Design em si. Deixa eu até apagar aqui que eu estava dando exemplo naquela hora aqui. E eu quero começar aos poucos aqui com vocês. Bom, dicas iniciais aqui em relação a essa parte do System Design. Normalmente, você sempre vai começar o System Design querendo fazer com que esses endpoints sejam resolvidos. Por outro lado, existem algumas coisas por padrão que a gente já pode pensar logo de cara. Por exemplo, quem vai fazer uma requisição é um usuário ou um client, da forma como você quiser chamar. E esse client vai ter que bater em algum lugar e normalmente, por padrão, o que a gente faz esse cara fazer? Por padrão, galera, é aplicação grande. Não precisa nem setar aplicações tão grandes. Hoje em dia, a gente tem o quê? API gateways. API gateways, no final das contas, eles são serviços que vão conseguir rotear o tráfego para a gente, certo? Mas também, eles vão tomar muito cuidado com a gente para a parte de autenticação, rate limiting e diversos outros tipos de serviço. Então, quer começar um system design e não ficar preocupado falando ah, o meu cara tem que ter autenticação, tem que ter isso, tem que ter aquilo? O meu, cara, tem que ter autenticação, tem que ter isso, tem que ter aquilo. Cara, API Gateway na frente, já estou tentando livrar qualquer tipo de pergunta. Se a pessoa, obviamente, quiser expor mais coisas, a gente pode aprofundar. Mas, lembrando, o nosso principal foco aqui, o que é? Esses caras aqui. O API Gateway me permite aqui me rotear para qualquer serviço que eu queira estar indo. E como que seria a parte mais simples de eu tentar resolver esse meu problema aqui? Eu teria, a forma mais simples seria eu botar aqui para mim um Post Service. Então, eu venho, meu API Gateway chega aqui eu consigo botar o meu Post Service o meu Post Service, o que ele vai fazer provavelmente, ele vai ter um banco de dados, então deixa eu pegar aqui um banco de dados vou tirar nesse momento se ele é relacional ou não depois a gente pode discutir sobre isso, sem problemas nenhum, mas eu quero dizer que esse cara tem um banco de dados aqui para mim, e aí eu vou botar, cair nesse meu post service aqui, no meu banco de dados. Eu caindo nesse cara, o que eu consigo fazer já aqui nesse momento? Eu consigo criar um novo post. Eu consigo dar aqui um create, um create post aqui para mim. Então, eu já matei aqui um requisito funcional que eu estava querendo trabalhar. Por outro lado, eu também posso fazer o seguinte. Eu posso usar, caso eu queira, o mesmo post service para eu também seguir um novo cara. Vocês concordam comigo? Dependendo da situação, eu posso querer usar esse serviço que eu estou postando para seguir e começa a já cair um pouco mal, né? Porque esse post, me parece que ele tem uma responsabilidade aqui bem clara, que é para criar novos posts ou gerenciar os meus posts. Seguir a coisa já começa a ficar um pouco diferente. Então, o que eu posso fazer aqui? Eu posso pegar um microserviço, ou um serviço, eu estou chamando tudo isso aqui de microserviço, da forma como vocês queiram nomear, tá? E eu posso ter um follow service, né? Eu estou chamando tudo isso aqui de micro serviço, da forma como vocês queiram nomear. E eu posso ter um follow service. Então, se eu quero seguir alguém, o que eu vou fazer? Eu vou chegar aqui e vou fazer, aqui no final das contas, o meu follow. Vou conseguir seguir o meu usuário. E, na hora que eu seguir esse meu cara, ele vai falar com o banco de dados aqui também. E não tem problema, estou apontando aqui para o meu banco de dados. Tenho um banco de dados aqui. Consigo ter os meus followers nesse meu mesmo banco de dados, por exemplo. Não tenho problema nenhum em ter um único banco de dados que tem os meus posts e que também tem a minha lista de seguidores que eu estou trabalhando aqui. Maravilha? E o que acontece que eu tenho aqui também? Eu tenho a minha parte de feed, né? Onde eu quero conseguir consultar os meus posts. Então nesse caso aqui, eu posso bater aqui por exemplo, eu vou até colocar aqui ó, que eu quero o feed desse usuário e E aqui, de forma geral, eu quase acabei o que eu estava querendo fazer. Porque provavelmente, na hora que eu for fazer um post de um service, eu vou precisar, por exemplo, guardar isso num banco de dados de storage. Estou colocando aqui uma fotinho do S3, para eu mandar informações aqui dessa minha mídia pra esse meu bucket. Galera, essa aqui é a solução, vamos dizer aqui, crua que tá fazendo eu resolver os meus requisitos funcionais, tá? O grande ponto é que isso aqui não resolve o meu problema quando eu estou começando a falar em escala, tá? Então, isso aqui é um ponto importante aqui pra vocês conseguirem entender, tá? Isso aqui, ele não vai suportar necessariamente escala. Por que que eu estou dizendo isso? Novamente, se eu for pegar o feed do usuário, como que eu vou montar esse feed? Né? Se eu vou criar o post do usuário, né? Como que eu vou jogar aqui, sei lá, 10 gigas pra dentro desse bucket diretamente? Então, tem algumas coisas assim, bem importantes que a gente pode tentar seguir pra matar esses requisitos não funcionais, tá? Por exemplo, a gente pode tentar seguir para matar esses requisitos não funcionais. Por exemplo, a gente tem aqui que nós precisamos ter uma latência muito baixa aqui para esse meu feed. Galera, esse tipo de coisa aqui é extremamente complexo, porque eu estou trabalhando com banco de dados. E aqui eu posso chegar, então, em momentos do tipo, ok, quais bancos de dados que eu poderia trabalhar e que resolveria esse meu tipo de problema? Honestamente, tá, pessoal? Nos dias de hoje, com as tecnologias de banco de dados que a gente tem, nós poderíamos trabalhar com diversos tipos de bancos de dados, tá? Existem alguns bancos de dados. Existem alguns bancos de dados que eles são bem característicos para resolver esses tipos de problemas. Um banco de dados aqui que resolve completamente esse problema sem nenhuma dúvida é o Postgres. O Postgres aqui, ele dá absolutamente conta para resolver esse tipo de problema que a gente tem. Um outro tipo de banco de dados que também facilitaria muito a nossa vida, que eu poderia trabalhar, e daí não é um banco de dados relacional, a gente poderia, por exemplo, trabalhar com o Cassandra. Ou a gente poderia trabalhar com o DynamoDB, por exemplo, que são bancos de dados orientados a... Eles têm tabelas, mas eles trabalham com colunas largas, onde eu consigo ter tabelas e essas tabelas vão conseguir trabalhar com os meus posts, com os meus feeds e etc. naturalmente. Então, tanto esses dois formatos de bancos de dados aqui, super em atende, provavelmente se você falasse Wesley, o MongoDB dá para colocar aí? Cara, provavelmente sim, mas da forma como eu tenho os meus dados aqui, para mim está muito claro que se eu for trabalhar tanto com Postgres ou tanto com um Dynamo, com Cassandra da vida, isso aqui resolveria bastante a minha vida. Uma coisa que é bem interessante, somente para vocês saberem, esse banco de dados do tipo Cassandra ou DynamoDB, eles trabalham basicamente com... Você cria, vamos dizer assim, tabelas, onde você tem ali os seus campos, ou seja, você tem, por exemplo, o seu ID do seu post, você tem as outras informações e aqui você pode falar que você tem uma, por exemplo, no caso o Dynamo, uma primary key e uma sort key, ou seja, uma chave para eu poder ordenar a minha tabela. Perceba que essas informações hoje em dia, e para esses tipos de serviço que eu preciso, é o máximo de utilização que eu vou ter. Eu não tenho tantos níveis de relacionamentos o suficiente para complicar esses tipos de coisa. Então, bancos de dados do tipo Cassandra, DynamoDB, eles são bancos de dados que tipo Cassandra, DynamoDB, eles são bancos de dados que funcionam muito bem pra esses tipos de problema, porque você consegue colocar os recursos que você tem, tá? Ou seja, você cria suas tabelas, você organiza quais são os seus índices de ordenação que você vai precisar e, basicamente, isso já vai resolver o tipo de problema que você acaba tendo, tá? Se você quiser play easy, vamos dizer assim, você pode falar, vou usar o Postgres, é um banco de dados parrudo, vai funcionar pra caramba. Inclusive, somente por curiosidade, o Instagram usa o Postgres, tá? Mas também o Instagram usa a Cassandra e tem diversos casos de uso, tá? Mas o Postgres é um dos bancos de dados, inclusive, principais que eles trabalham nos dias a dia. A diferença desses dois caras em relação à abordagem. Se eu for trabalhar, por exemplo, com DynamoDB, é um serviço gerenciado da AWS e eu não tenho muita preocupação necessariamente com escala, com sharing e com coisas desse tipo. Cassandra, eu posso ter o meu cluster onde eu gerencio, também tem serviços gerenciados para isso. Ou se eu for utilizar, por exemplo, Postgres, vai depender muito do tipo de serviço que eu vou querer trabalhar. Por exemplo, se eu quiser pegar, por exemplo, um Aurora da AWS, ela vai me resolver bastante o meu ponto aí de de sharing, de escalabilidade com o meu banco de dados mas se eu quiser isso, fazer isso de forma manual por exemplo aqui no meu post e eu gerenciar meus próximos meus próprios bancos de dados eu vou precisar trabalhar com processos de sharing e replicação dessas informações a parada fica mais complexa, mas acaba sendo mais barato. Então, dá para você ter ferramentas, Citus, por exemplo, para o Postgres, é uma ferramenta super ok, que vai conseguir resolver esses tipos de problema também aí. Para a gente play easy aqui, eu vou colocar que a gente está trabalhando com Postgres, mas eu poderia colocar aqui tranquilamente um DynamoDB ele entraria bonito para eu trabalhar principalmente porque aqui eu estou muito mais preocupado com dados e ordenação dos dados do que necessariamente muitos relacionamentos então basicamente isso e o Postgres cai bem porque se eu trabalho com índices aqui, eu vou ter uma latência extremamente baixa para eu conseguir bater aqui no meu banco de dados. Então, eu acho que aí é um ponto importante para a gente falar. Agora, a coisa começa a ficar mais complicada quando a gente começa a falar do feed, o grande problema, um dos grandes desafios de resolver esse system design é esse cara aqui. Por que eu estou dizendo isso? Porque está muito claro que se eu baixar, bater toda hora nesse banco de dados, esse meu banco de dados não vai dar conta. Independente se eu tenho um trilhão de réplicas desse banco de dados. Eu ficar batendo em banco de dados dessa forma é gastar dinheiro à toa. Porque eu tenho bancos de dados específicos para eu ficar pegando esses dados rapidamente num formato de cache. E aí, nesses momentos, a gente pode ter um Redis da vida, um ManCached, por exemplo, para fazer isso. Por curiosidade, só para vocês saberem, eu acho que o banco de dados padrão de cache, que tem mais uso no Instagram, é o ManCached. Eles também utilizam Redis. Mas aqui, a gente pode falar especificamente de Reds. Mas a questão aqui não é apenas falar, ah, eu vou botar um cache, então a coisa vai ficar mais fácil. Então a gente poderia chegar e fazer assim, olha só. Poderia chegar e falar assim, olha, eu tenho um cache aqui, né? Tenho um banco de dados de cache. Então toda vez que eu quiser ler meu feed, eu vou bater aqui no cache primeiro, se ele tiver um miss, ele bate no banco de dados, caso não, ele lê do cache e economizou esse cara aqui. Mas, na real, galera, essa não é uma boa solução, trabalhar simplesmente dessa forma, porque o nosso feed é completamente dinâmico e a gente vai precisar de muito mais do que simplesmente chamar o banco de dados para a cache aqui. Porque a gente tem que entender a complexidade que a gente tem. Olha só que interessante. Vamos pensar no seguinte. Eu tenho o Wesley, tá? E o Wesley está seguindo ali o o Sérgio tá seguindo o Leonan, tá seguindo o Neymar, tá seguindo qualquer outra pessoa aqui, beleza? Então o que que acontece? O meu objetivo aqui no meu feed é ter os posts, os últimos posts aqui do Sérgio, do Leonan e do Neymar aqui no meu feed. Com a lógica que a gente pode ter aqui, o que normalmente, naturalmente a gente faria? Eu vou no meu banco de dados, consulto, vejo quem são os meus seguidores. Pego a lista dos meus seguidores e falo assim para mim, olha, os seus seguidores são esses caras aqui, são esses IDs aqui, são meus seguidores. Pego a lista dos meus seguidores e falo assim para mim, olha, os seus seguidores são esses caras aqui, são esses IDs aqui, são seus seguidores. Falo, beleza, agora eu sei quem são meus seguidores. Agora, o que eu vou fazer? Eu vou pegar aqui e vou consultar os posts do Sérgio. Depois, eu vou consultar os posts do Leonan depois disso eu vou consultar os posts do Neymar depois disso eu vou dar um merge nisso aqui e conseguir o meu resultado aqui no meu feed tá agora vamos imaginar que eu estou seguindo mil pessoas. Independente se eu tenho um post-service, se é feed-service, não interessa. Vocês concordam que isso aqui cheira mal pra caramba? Vocês conseguem se ligar que esse tipo de coisa, para eu fazer isso com uma latência de 400 milissegundos, é um trabalho muito duro e é muito pesado. Cooperação, isso aqui é chamado de fan out on read. O que isso significa? Que o Wesley vai ter que ver seus seguidores e os seguidores pegar os posts dos seguidores. Então, eu saio ampliando esse leque para um monte de gente, caçando posts de todo mundo. E isso aqui é fan out on read. É errado isso? Não. Você usa isso no dia a dia? Com certeza, a gente pode até usar, mas o importante é a gente entender esse grau aqui de complexidade. Então a gente já começa a perceber que simplesmente apenas falar que eu vou botar um reds aqui não vai resolver o meu problema, porque o meu problema é um buraco mais embaixo. O meu problema aqui é exatamente evitar esse tipo de processo. Então, o que eu posso tentar fazer para me aliviar aqui um pouco? Somente para a gente não ficar misturando muito as bolas de post e service, eu vou criar aqui um feed service aqui pra mim, tá? Mas esse meu feed service, a gente vai trabalhar com uma lógica um pouquinho diferente nesse cara aqui, tá? Vai funcionar da seguinte forma. Eu sim, eu vou botar um cache aqui pra mim. Tá? Eu vou botar um cache. Vou botar, sei lá, o meu Reds aqui, ó. Até escrever aqui, Reds. Esse cara. Então, eu tenho aqui o meu cache e tô feliz da vida e tudo mais. O problema é que, como que eu gero em cache isso aqui, que é dinâmico? Então, existem algumas formas de como você resolver esse tipo de problema. E esse problema, ele é o ao contrário do fanout on read, que na realidade ele é chamado de fanout on write. Então, o que que eu faço? Ao invés de eu consultar o meu cache para eu ler apenas o meu feed, eu vou deixar esses dados pré-computados. O que isso significa? Significa que toda vez que eu criar um novo post, que eu criar um novo post, eu já vou escrever aqui esse cara no meu Reds, no meu cache. Mas eu vou fazer algo um pouquinho diferente. Eu vou trabalhar da seguinte forma. Olha só que interessante. Eu posso fazer o seguinte. Eu posso pegar assim, ó. Alguém, todo mundo aqui já trabalhou com Redis? Todo mundo aqui já trabalhou com Redis? Tem ideia, né? Redis é um banco de dados em memória, né? E ele trabalha muito com chaves. Então, o que eu posso fazer? Eu posso fazer o seguinte, eu posso pegar, por exemplo, uma chave de feed, eu posso pegar aqui o user ID do cara, legal? E aqui dentro, o que eu posso fazer? Eu posso pegar o post inteiro que foi feito e colocar no feed desse usuário. Ou eu posso pegar só o ID do post. O que que eu tô querendo dizer com isso? Tô querendo dizer o seguinte. Vamos imaginar que o Wesley tá seguindo o Sérgio, o Leonan e o Neymar. O que que vai acontecer agora? Quando o Sérgio fizer um post aqui pra mim, o que que eu vou fazer? Eu vou verificar quem são os seguidores do Sérgio. Legal? Ou seja, eu vou ter o ID dos seguidores do Sérgio. E aí, o que eu vou fazer em segundo lugar? Eu vou adicionar no Redis, ali, o quê? Eu vou falar o seguinte, eu vou colocar feed, eu vou colocar Wesley ID, somente pra você saber, e vou colocar aqui, ok? Do Wesley, o post do Sérgio. Fez sentido o que eu estou falando aqui para vocês, galera? Então, o que acontece é o seguinte, todas as vezes que alguém fizer um post, eu vou no meu Redis e vejo quem são os seguidores desse cara e adiciono no feed dele os posts de quem ele segue. O que isso significa na prática? Quando eu, Wesley, for chegar aqui para ver o meu feed service, o que eu vou fazer? Eu vou bater aqui nesse meu banco de dados, nesse meu Reds aqui, e eu já vou ter aqui todos os posts que já fizeram aqui para o meu perfil. Então, isso aqui a gente vai fazer. Galera, quem está falando de Neymar, Cristiano Ronaldo, etc., relaxem, vamos devagar, vamos devagar, Tem para todo mundo. Vamos lá. Então, o que acontece? Eu fazendo dessa forma aqui, eu consigo fazer com que eu evite toda hora que eu for entrar no meu Instagram e ver meu feed, eu ficar batendo ali no banco de dados. Batendo o banco de dados e fazendo esse fanout on read. Porque isso claramente aqui pode dar muito ruim. Legal? Então, isso aqui resolve um pouco a minha vida. Mas eu tenho que decidir uma coisa. Eu tenho que decidir se para mim vale a pena eu colocar já o post inteiro do cara aqui, ou seja, o título, o ID da imagem, a descrição do post e etc. Ou eu colocar o post ID apenas aqui do cara. Quais são as vantagens e desvantagens aqui nesse nosso cara? Colocar o post inteiro facilita muito mais a minha vida por um único motivo. Se eu pegar apenas o ID, eu vou ter que, de qualquer forma, bater no banco de dados para pegar o conteúdo do post. Esse é um ponto. Porém, se eu coloco o post inteiro e o usuário edita o post, eu vou ter que sair alterando todos os feeds de todos os usuários com o dado daquele post. E aí eu gero esse tipo de problema que eu tenho aqui. Você entende? Eu tenho esse tipo de problema, que é em relação à parte de consistência. São decisões que eu tenho que tomar. Mas talvez eu consiga trabalhar de uma forma um pouco mais híbrida. Que seja como, eu tenho aqui o meu user ID e o meu user ID, realmente eu pego o post ID. Mas o que eu posso fazer também aqui é o seguinte, eu posso ter aqui o meu post ID com o dado do meu post inteiro. Então, quando eu bater no meu banco de dados, o que eu vou fazer? Deixa eu tirar o feed aqui da frente. Eu vou olhar o meu user ID do Wesley. O Wesley vai pegar todos os posts ID que ele tem no feed dele. Aí eu volto aqui no meu banco de dados, aqui no meu próprio Redis, e dou um emigete aqui, pego todos os conteúdos dos posts que eu preciso. E aí eu tenho o meu feed feito aqui por inteiro também. Fez sentido para vocês até agora isso que eu estou falando, galera? Deixem-me saber aqui se vocês estão conseguindo seguir essa minha linha de raciocínio. Se alguém quiser levantar a mão e fazer alguma pergunta, fiquem à vontade. Respondo umas duas perguntas pra gente continuar e também não demorar, fazer a coisa mais demorada do mundo. Gabriel aí, bota a câmera. Galera, pergunta só com câmera, tá? Então, Gabriel, bota a sua câmera, cara. Um minuto, rapidinho. Alguém pode fazer a pergunta aí na frente. Eu estou só ajeitando aqui a câmera. Ah, show de bola. Bora aí, doutor Elias, cara. Fala comigo, meu amigo. Fala, grande Wesley e participantes. Primeiramente, obrigado pela oportunidade. Foi muito legal, cara, esse exercício que a gente fez de System Designer. Mas, pô, foi show Esse exercício que a gente fez de System Designer Mas Foi show Não conseguia avançar muito não no sistema Do designer Mas a gente chegou Foi bem legal o que a gente fez Foi tipo Mas enfim, vamos fazer a pergunta Não é longa Manda lá A gente estava comentando aqui no chat Que tem os problemas De Usar o Reds, por exemplo Para um Neymar, que tem Um bilhão de seguidores E aí, se por exemplo A gente tiver problema de Perder o cache Ou ter que atualizar o cache Ou invalidar o cache E acabar perdendo o cache Não é muito custoso a gente usar o Red para isso? O que você teria de solução nesse caso? Porque eu não sou mestre de arquitetura de soluções. Vamos lá, cara. Casos de Neymar, quem tem muitos seguidores, eu já adianto para vocês que eu vou falar em seguida. Mas em relação de custo Red, perder cache, essas coisas, cara, isso pode ficar absolutamente tranquilo. Redis é uma ferramenta extremamente forte, ela é extremamente poderosa, ela consegue trabalhar com shardings, você tem que ter técnicas inclusive pra conseguir mapear as keys, pra conseguir equilibrar e tudo mais, mas, de forma geral, esse tipo de coisa é uma estratégia, assim, já muito bem consolidada de você fazer esse tipo de movimento, tá? Ou seja, você conseguir fazer essas inserções cada vez que um post entra e fazer essas leituras massivas. É exatamente isso que o Redis vai trazer aqui pra gente. o Reds vai trazer aqui pra gente. Se a gente achar que o Reds, por exemplo, é custoso, imagina o quanto que não vai ser um posto gris da vida, entendeu? Mas eu preciso da licença poética ainda pro caso do Neymar, tá? Mas o ponto principal que eu quero que vocês peguem a ideia é essa ideia do fan-out on-write. Fez sentido para vocês? Ah, eu acho que ele saiu, mas... Fez sentido. Fez sentido, né? Invalidação de cache, esses tipos de coisa, a gente vai falar... Eu vou dar uma profunda... Se vocês toparem, galera, eu posso ficar até um pouquinho mais aqui com vocês, e aí eu posso dar um pouco mais de detalhes, como é que a gente poderia trabalhar com o Redis com o Cache, sei lá, o comando que a gente utilizaria no Redis, se vocês quiserem a gente pode aprofundar um pouquinho mais, tá? Talvez a minha esposa fique brava mas, bom, vamos ver como é que vai seguindo o fluxo aí, fechou? Então, essa que é a ideia. O Gabriel, manda aí, Gabriel. Pô, cara, você é bonito. Fala a verdade. Você não estava com a câmera porque você estava se maquiando antes. Fala a verdade. Estava sem camisa, está calor aqui. Cara, então, basicamente a minha pergunta é qual seria o tamanho desse Redis para eu cachear todos os meus User IDs? Na realidade na realidade você não fica pensando no tamanho do seu Redis, o que você tem que pensar é que o seu Redis, ele é shardeável você vai ter várias instâncias de Redis escaláveis, então eu não fico preocupado em ter um Redis único, porque jamais isso daria conta, tá então e eu também teria que saber de alguma forma em qual sharde está a informação do aquele meu usuário que eu quero exato tem algumas estratégias que garantem isso saber de alguma forma em qual shard está a informação do aquele meu usuário que eu quero, né? Tem algumas estratégias que garantem isso. Exatamente isso, porque conforme você cria um registro no Redis, ele vai alocar para um shard específico. E aí, a grande beleza de trabalhar com Redis, na realidade, principalmente quando você está trabalhando em shardings, é você conseguir criar estratégias de keys pra que você tenha um balanceamento muito próximo pra você não deixar um Shard com muito dado estourando memória e um outro Shard ali só na boa, né? Então, mas daí é... vai ficar pra aula de Reds que o Ricardo Ferreira, que trabalha na Reds vai dar em algum momento pra gente no MBA, se vocês se inscreverem, tá? Mas somente pra... Mas é basicamente isso, tá, Gabriel? Bom, de nada mais é. Fala, doutor Danilo. Fala que eu te escuto. Só não sei se eu sei responder, mas pode falar. Boa noite, gente. Não, na verdade, a problematização que eu estava fazendo é mais do caso do Neymar mesmo. Então, não sei. Porque é aquela coisa, né? Ele tem 100 milhões de seguidores, então ele fez um post e tem que... Inserir 100 milhões de usuários, né? Então, mesmo que não seja uma alteração, ainda é uma coisa muito cara, né? E, eventualmente, você está atualizando ali você tem 100 milhões de seguidores mas só 5 milhões estão online naquele momento então se não era uma solução mais de worker que atualiza, vê quem está logado e atualiza o feed de quem está logado de 3 em 3 minutos, alguma coisa nessa linha, sabe? Show, cara como eu falei pra você, não necessariamente eu vou responder sua pergunta não chegou ainda, mas, cara faz todo sentido e a forma como você falou tem, dá pra usar exatamente essa estratégia em relação de quem tá online são coisas de workers que trabalham com inteligência e tudo mais, mas eu vou trazer aqui pra vocês uma estratégia um pouco diferente que funciona muito bem também, mas galera, aquela história, é system design você tem que trazer uma informação uma forma e pode discutir os outros, tá? Eu tô seguindo essa linha, principalmente nesse momento, porque a gente tem esse desafio inicial aqui do fanout, o Riot, pra acabar com o grande problema desse cara aqui. Porque apesar de ter muito mais usuários normais do que Neymar no Instagram. E o meu grande problema aqui é que, ok, o Neymar eu sei que ele é um cara separado. São casos separados inclusive. Mas o Joãozinho, o Pedrinho e esse cara, fazer o fan-out on region desse cara custa muito caro. E é nesse ponto aqui que esse tipo de estratégia ele acaba seguindo. Antes de eu voltar e continuar respondendo as perguntas, mantenha as mãos levantadas, porque daí eu volto em vocês, se não, somente pra eu conseguir seguir meu raciocínio, se não acabo me perdendo, tá gente? Então, espero que tenha ficado claro qual que é a nossa ideia agora aqui. Então, cada vez que eu fizer um novo post, né, o Sérgio fez um post, eu vou lá no usuário do Wesley e boto o post do Sérgio. O Leonan fez um post, vou lá no feed do Wesley e boto o post do Leonan. Quando o Wesley acessar, o que vai acontecer? Eu bato no meu banco de dados, pego todos os meus posts ali e já mostro o meu feed com uma latência extremamente baixa e estou tudo bem aí com isso, tá? Então, essa solução aqui, no final das contas, ela nos ajuda a gente a conseguir trabalhar dessa forma, vamos dizer assim, pré-computada, pré-computed, eu não sei, pré-computada pré-computada vou escrever aqui eu vou colocar aqui deixa eu escrever aqui cache pré-computado e aqui eu vou colocar fanout on write, tá? Que é esse, vamos dizer assim, padrão que a gente está trabalhando aqui nesse caso. Beleza? Quando o feed service do Wesley bater, ele vai bater no redis e eu estou feliz da vida aqui para mim, tá? Temos agora o outro problema, que é o que vocês estavam falando aí com toda razão, que é o problema do Neymar, né? Vamos lá, o lance é o seguinte o Neymar tem milhões e milhões aí de seguidores significaria que se eu trabalhar com o Neymar no formato fan out on right significa que cada post do Neymar geraria uma inserção em 229 milhões de seguidores, o que acaba não fazendo sentido nenhum. Da mesma forma, quando a gente olha isso, não faz sentido. Quando a gente olha isso aqui para o caso do Neymar, Cristiano Ronaldo, 653 milhões. Isso também não faz sentido. Concordam comigo? Nesse tipo de caso, eu posso trabalhar da forma híbrida. Eu posso criar uma regra, algo do tipo. Se eu tenho, sei lá, 100 mil seguidores, pode ser qualquer número, tá? Se eu tenho até 100 mil seguidores, eu vou simplesmente fazer aqui para mim o fanout on right. Se eu tenho mais de 100 mil seguidores, estou dando um exemplo no caso aqui do Neymar, eu vou fazer o fanout on read. Ou seja, assim, no caso do Neymar, ao invés de eu sair inserindo no banco de dados de todo mundo, o que eu vou fazer? Eu vou fazer um merge desse cara. Ou seja, eu vou pegar todos os caras que são fanouts on read, que são pequenos aqui pra mim, pra eu não matar meu banco de dados, mas quando eu tô falando aqui no caso do Neymar, o que eu faço? Eu posso fazer o fanout on read aqui nesse meu caso, aqui também, e eu não vou ter problema nenhum. O que acontece é, quando eu acesso, vai sobrar o ID do Neymar ali pra mim, do Neymar e do Cristiano Ronaldo. Na hora que sobrar esses IDs, eu falo, opa, não achei esse cara no Reds, deixa eu bater esse cara aqui. Ou, muito pelo contrário, eu faço a chamada simultânea. Eu vejo a quantidade de seguidores que esse cara tem, se esse cara passou daquele nível de seguidores, eu já vou buscar ele direto no banco de dados simultaneamente enquanto eu vou bater ele no Reds. Eu faço as duas consultas simultâneas, recebo esses dados, faço o merge e consigo listar aí no feed. Faz sentido isso pra vocês? Melhora um pouco mais essa resolução, galera? Começa a melhorar, né? Porque aí eu começo a pegar um pouco do melhor dos mundos, né? Eu começo a bater no banco quando eu não tenho que inserir muitos dados, mas eu não preciso bater no banco o tempo inteiro na hora que eu vou fazer esse fanout on read aqui. Porém, se você quiser ir num limite um pouco maior ainda, a gente pode fazer uma arquitetura ainda mais híbrida. A gente pode fazer o seguinte. A gente pode pegar aqui algo como... Trending... Trending... Vou colocar, sei lá, celebridades. Tá? Aqui. E nessas celebridades, eu coloco aqui o ID do Neymar. ID Neymar. ID Neymar. E aqui eu coloco todos os posts que o Neymar fez. Então, o que pode acontecer é o seguinte. Eu posso chegar e fazer uma outra regra aqui para mim. Eu posso fazer o seguinte. Se o cara tem mais que, sei lá, 10 milhões de seguidores, eu busco no Trending Celebrities, sei lá, uma coisa assim, tá? Eu busco o índice de celebridades, com S tá bonito, né? Celebridades. Aí eu posso pegar, fazer essa conta aqui. Aí eu consigo justificar um pouco mais, porque se eu fizer isso para todos também não vai rolar. Eu posso pegar, sei lá, o top 1%. Eu posso fazer alguma conta ou colocar um número de corte. Então, nesse caso, a gente consegue evitar o problema do dia a dia com o Fanalton Read, certo? Porque eu vou fazer o Fanalton Write nos meus problemas. No caso de um cara que tem muito seguidor, né? Eu posso bater direto no banco, fazendo o Fanalton Read. E, no caso que o cara tem seguidor pra caramba, o que que eu vou fazer? Eu posso criar um cara aqui no Redis específico aqui pra ele, tá? Então, essa é a ideia de como que a gente consegue trabalhar aqui, tá? Ah... Fernando, tava com a mão levantada. Pergunta, meu querido. Nunca tive um problema desse para poder trabalhar. Durante esse momento da leitura, eu imagino que a questão não deveria ser no momento em que se faz o post, mas no momento em que se tenta montar o feed. Porque o fato de do Neymar ter quase 230 milhões de seguidores, não quer dizer que todos esses seguidores vão ver esses posts. Cada seguidor tem uma quantidade de pessoas que ele segue e se eu entrar no Instagram, eu vou ver algumas coisas. Eu não vejo tudo de todo mundo que eu sigo. Então, eu tenho a impressão de que se eu fosse desenvolver uma coisa dessa, eu estaria preocupado mais em montar uma estratégia, utilizando basicamente o mesmo raciocínio que você tem, eu montaria alguma coisa para poder fazer uma espécie de buffer circular em relação às pessoas que o usuário segue, de forma que eu poderia, ao longo do tempo, ir passando em todos os usuários pra, não sei a impressão que eu tive eu entendi perfeitamente, o grande ponto, olha aqui o nosso requisito de engenharia, usuário ter acesso ao feed com postos dos usuários que ele está seguindo, ponto galera a gente não é especialista aqui em Instagram em Machine Learning, qual usuário que é o melhor pra eu mostrar de acordo com engajamento e etc a gente não consegue entrar nessa seara porque, cara nem a própria galera que trabalha provavelmente no Instagram, todos conseguem entender inclusive esse algoritmo porque são coisas extremamente complexas o que a gente tá querendo focar aqui é no nosso system design da forma mais clara possível no nosso requisito funcional, o usuário terá acesso ao feed com os posts dos usuários que ele está seguindo. Então, o que eu preciso ter aqui muito claro para mim é como que eu consigo ter acesso aos posts que os usuários que eu estou seguindo eu consigo ver. Fez sentido? Tem sim. Me falhou de me prender a esse requisito aí. Uma outra questão é que se eu fosse implementar, eu não utilizaria Redis para poder armazenar essa informação, porque às vezes pode gastar dias para a pessoa, para poder se ver esse post. Então, eu usaria um banco normal. Você acha que isso seria... Seria, na minha opinião, um gasto absurdo de dinheiro, porque o banco normal não vai conseguir ter uma latência tão baixa como o Redis, ele vai ser mais caro porque ele vai ter esse acesso de consultas gigantescas que o Redis consegue responder muito bem o ponto, quando a gente está falando do Redis se o cara pode demorar um tempo pra ler isso aqui é simplesmente ter uma política tá, de uma política de invalidação de cash. Aí, automaticamente, eu posso falar, esse post aqui que está trending, ele pode ser removido quando acumular 20 posts daquele cara. Ou esse post pode ser removido daqui a dois dias. Automaticamente, o Redis pode remover. Então, a gente pode ter regras e políticas de invalidação de cash, e isso aí acaba não sendo... Não vou dizer que isso é de menos, porque tem várias estratégias que você pode utilizar para invalidar. Mas, de forma geral, cara, esses tipos de Caso, eles imploram Para um Redis ou algum banco de dados Em memória, porque é a forma mais rápida De você conseguir pegar Esse tipo de dados e de informação Entendeu? Muito obrigado Fechou? Arthur? Opa, fala aí Wesley, beleza? Boa noite, cara Mano, eu tenho uma dúvida assim eu acho que vai até relacionar mais com essa segunda solução que você deu agora que você falou da questão do Neymar e tudo mais ali no Redis a ideia é guardar por User ID uma lista de Post ID, de forma que o feed esteja guardado dentro dessa chave, certo? Exatamente. Beleza. Aí, cara, eu vi que no seu design, ali na descrição da API, você colocou o feed passando um offset e um limit. Com a ideia, eu acho que ali seria fazer uma espécie de scroll infinito, certo? É, um cursor onde eu posso ter a liberdade de eu conseguir trabalhar com isso. Beleza. Mas aí, tipo, como é que a gente, tipo, como é que você faria pra acelerar, tipo, você tá se importando em acelerar essa pesquisa a nível de página também? Ou você só traz aqui e filtra um demente? Qual seria o tamanho dessa lista no Reds? Ela ficaria infinita? Cara, não sei. Nesse momento, no Citizen Design, eu não preciso pensar em detalhe de tamanho de lista. Entendeu? Porque isso, basicamente, acaba virando uma regra de negócio. Se eu falar assim, olha, vou botar 100 pessoas, no máximo, no ID no meu feed. Entrou gente nova, eu posso pegar o cara que nunca foi acessado e jogar aquele cara fora, porque daí ele acabou não vendo mesmo e passou muito tempo ou coisas desse tipo, entendeu? Então, basicamente, tamanho de lista, quantidade de pessoas, esses tipos de coisa digo, nesse contexto pra gente é muito mais uma decisão meio que de negócio, usabilidade ou qualquer coisa desse tipo do que necessariamente como se diz um problema específico de na hora do system design não entendeu? Não sei se fez sentido o que eu tô querendo dizer. Tá. Assim, basicamente, assim, eu tô entendendo que isso foge um pouco do contexto do problema que a gente tá tentando tratar aqui. É mais ou menos isso, né? Tipo, se a gente fosse fazer isso no dia a dia, na vida real, a gente teria que levar em conta mais coisas do que esse programa que a gente está aqui. Se eu contar no mundo real, esse design acaba sendo inocente, entendeu? Sim, sim. Ele é inocente e mesmo assim, se você olhar, tem complexidade aqui, né, cara? Não é um problema simples, mas sem dúvidas, tem, cara, só de processos, por exemplo, de invalidação de cache, por exemplo, você vai querer que também que os posts apareçam em ordem cronológica, né, do mais novo pro mais último, então você vai ter que, sei lá, usar um sorted set no Redis, por exemplo, aí você vai pegar esse cara pela data cronológica. Então, assim, tem várias formas, eu posso buscar um ZREV range para pegar os últimos tantos que eu estou querendo naquele momento, naquele feed. Então tem, assim, a gente está bem servido nesse caso, falando especificamente do Redis, porque ele tem todos os recursos que a gente precisa de pegar os últimos, ou eu sempre faço o seguinte, cada vez que eu acessar aquele cara, eu pego, sei lá, os 20 primeiros e os de tanto pra frente, eu já removo os mais antigos automaticamente, eu já dou um remover nesse cara ali pra gente. Então a gente consegue fazer bastante coisa desse tipo. Tem bastante opção com Redis, o Redis é algo interessante porque ele tem um monte de funçãozinha que quando você junta elas você consegue brincar, criar as keys apagar os caras mais antigos unir vários sets de caras, um cara só então tem bastante opção que você consegue trabalhar com Redis pra fazer esse tipo de coisa. Fechou? Legal. Pessoal, vou continuar e depois eu vou seguindo aí com as perguntas. Espero que esteja fazendo sentido pra vocês no que eu tô falando. Mas, de forma geral, isso aqui, meio que, entre aspas, como eu digo resolve essa dor grande que a gente tem do FID, galera, porque é um problema de gente muito grande essas duas situações aqui e quando eu digo que é problema de gente grande, é que é extremamente trabalhoso, tem diversas formas que você pode trabalhar mas a gente tem que continuar com o nosso sistema de design, porque, cara, ele está meio que longe ainda de acabar. Tá? Ele está um pouco longe ainda de acabar. Por que eu estou dizendo isso? Porque o lance é o seguinte, toda vez que eu fizer um post, né, esse post, eu não quero ter a chance necessariamente de, não necessariamente perder o post, mas eu quero poder fazer coisas com esse post. Por exemplo, colocar esse post na hora que ele for criado no Redis não precisa ser uma tarefa síncrona. Ele pode ser uma tarefa, por exemplo, assíncrona. Então, o que eu poderia fazer aqui no meu caso? Eu poderia pegar uma fila e aqui, tanto faz, não estou preocupado qual é a tecnologia. Poderia ser um RabbitMQ da vida. By the way, o Instagram por muitos e muitos anos usa ainda o RabbitMQ. O que acontece, o Instagram, por muitos e muitos anos, usa ainda o RabbitMQ. O que acontece é o seguinte, saiu um novo post, o que eu vou fazer? Eu vou gerar esse cara e vou colocar esse cara aqui na fila de novo post. Estou feliz e contente aqui, botei esse cara aqui, novo post. O meu feed service, o que ele vai fazer também? Ele vai receber os dados desse meu post e vai pré-computar esse cara aqui. Então, eu vou jogar aqui o cache pré-computado aqui para o meu feed service e fazer esse cara aqui para mim. Acabei de receber esse novo post. Uma outra coisa também, que é um outro problema que eu tenho e que a gente ainda não resolveu, tá? É que esse upload aqui da forma como ele tá, ele não tá legal. E o porquê que eu digo isso? Cara, você não vai fazer um microserviço seu, tentar subir um giga, quatro gigas, quinhentos megas, diretamente num bucket da S3 ali. Você tem uma chance muito grande de perder dados. Mas existem estratégias que vão te ajudar a fazer isso. Uma das estratégias bastante utilizadas aí é fazer o quê? É trabalhar com URLs pré-assinadas. Deixa eu ver se eu consigo mudar a minha setinha aqui. Como é que eu mudo a minha setinha? O que acontece é o seguinte, galera. Quando eu for criar um novo post, deixa eu ver se eu consigo usar esse cara aqui. Quando eu for criar um novo post, oh meu Deus. Vocês entendem porque às vezes desenhar na frente dos outros você passa vergonha, né? Na hora que eu vou criar um novo post, eu faço a criação do post, mas nesse momento eu recebo uma URL pré-assinada para mim. Essa URL pré-assinada... Essa URL pré-assinada, ela vai me dar um link para eu subir o meu vídeo diretamente para cá. O meu vídeo, a minha imagem, não interessa o quê. Então, o que acontece? Ao invés da minha criação, do meu post, do meu upload, passar aqui por dentro e ir caindo para todo esse lado, eu consigo já fazer o upload diretamente para o meu bucket, sem passar pela minha infraestrutura. Então, isso aí muda o jogo absurdamente aqui para mim. Então, isso aqui para mim é importantíssimo. Por outro lado, isso também ainda não resolve todo o meu problema. Por quê? Porque eu ainda tenho uma dor aqui. E a minha dor é, se eu subir um vídeo de 1 giga, obviamente que eu não vou colocar no feed do usuário um vídeo de 1 giga. Então, o que eu posso fazer? Eu posso ter um serviço ou até usar um serviço externo, daí não interessa, pode ser um media convert, independente do serviço. Eu vou cham pode ser um media converter, independente do serviço. Eu vou chamar aqui de media converter. Esse cara aqui, o que ele vai fazer no final das contas? Ele vai ficar lendo o tempo todo os posts que a gente acabou de subir, mas que ainda não foram convertidos. Então, eu vou colocar aqui somente uma observação, onde... Meu Deus, aqui... Vou colocar aqui como observação, onde o status do post é apenas, É apenas, por exemplo, uploaded, né? Ou alguma coisa desse tipo. Por que que eu tô dizendo isso? Quando esse status mudar, por exemplo, pra uploaded ou alguma coisa desse tipo, o que que eu simplesmente posso fazer? Aí existem algumas técnicas, tá, galera? Aí vai depender de como que você pode fazer. Uma técnica é você, por exemplo, se você tá trabalhando na AWS, você pode pegar uma notificação, tá? Um SNS da vida e toda vez que esse cara for concluído, for feito o upload, ele notifica e esse cara aqui começa a trabalhar. Tá? Então, essa é uma forma de a gente conseguir ver isso dessa forma. Então, eu posso ter alguma espécie de alguma fila que eu possa receber informações quando um dado foi acabado de feito, uploaded. Então, posso colocar aqui uploaded media. E aí, toda vez que um dado for uploadado, vamos dizer assim, eu vou pegar essa informação. Deixa eu mudar o tipo da minha seta aqui. Eu vou pegar essa minha informação. E vou começar a fazer a conversão desse vídeo, ou da imagem, da melhor maneira possível que siga os meus padrões. Uma outra coisa que para mim também é importante, é que toda vez que eu terminar de converter esse cara, eu posso ter uma outra fila aqui para mim, onde eu posso colocar converted media. Ou seja, a mídia já foi convertida. E aí esse meu media converter manda uma mensagem para esse cara e esse meu post service aqui vai conseguir ler essa fila aqui. É basicamente isso. E aí esse cara vai atualizar o status falando que esse post está pronto para ser publicado. Fez sentido isso para vocês, galera? Deixa eu voltar aqui na parte das dúvidas. Se alguém teve dúvida nesse movimento que a gente fez, deixa me saber. Edson, manda ver aí, cara Boa noite, pessoal Wesley, voltando um pouco ali pra questão do fanout, né no caso de usuários que tem muitos seguidores, como o Nirmal, o Cristiano Ronaldo ou algum outro artista faria sentido fazer uma pesquisa, digamos, num banco de grafo, algo do tipo, que tem essa relação entre os usuários, de quem segue e quem é seguido, pra saber quem são os usuários que estão online e só daí de então jogar essas informações no Reds, no post? Ou não? Então, novamente, aquele negócio. Se eu olhar fixamente pros meus requisitos funcionais, eu não vou nem levar isso em consideração. Porque eu quero ver meus usuários que estão seguindo, etc. E não estou pensando em coisas desse tipo. Agora, obviamente, tá, galera? Inclusive, a própria meta tem uma ferramenta que chama TAL, né? Que é um banco de dados em grafo deles. Esses bancos de dados em grafos, eles são muito importantes para você saber esse cara segue aquele, que segue esse, que segue esse, que tem todo esse nível de complexidade. Especificamente para esse problema que a gente precisa resolver, a gente não precisa desse banco de dados em grafo. Definitivamente. Porque a gente só precisa saber os IDs dos caras. Agora, se nos nossos requisitos mudassem e falassem grafo, definitivamente porque a gente só precisa saber os IDs dos caras agora se nos nossos requisitos mudassem e falassem mostre também em 10% dos casos os posts de algumas pessoas que o Neymar segue para o Wesley aí a coisa começa a mudar porque daí eu já começo a ter conexões entre outros caras. Aí eu começo a, como se diz, a mudar um pouco o escopo da coisa. E, obviamente, empresas, Instagram e coisas desse tipo, eles usam, sim, esses tipos de banco de dados para conseguir ter esses níveis de relacionamento, tá? Mas, de forma geral, galera, estou focadaço aqui naqueles meus requisitos. E recomendo a todos, pessoal, quando vocês forem participar de uma entrevista de System Design, principalmente entrevista, é foco absoluto, não pira, não, porque tem aquele cara não sei o quê, cara, não tem mecanismo nenhum, entendeu? O que está pedindo ali, sacou? Falou em mecanismo nenhum, entendeu? Tá? O que tá pedindo ali, sacou? Falou em mecanismo, etc, você já caiu numa seara que você não entende. Eu não entendo nada de rede social, como é que os caras organizam a feed deles, se é base de interesse, se é por cliques. Eles têm uma super ferramenta de machine learning pra conseguir criar toda essa curadoria, a parte de conteúdo que eles censuram de acordo com o tipo de... Cara, deve ser uma loucura, né? Pra gerar um feed no Instagram, né? Da mesma forma como é pra gerar o feed do Twitter, do Facebook. Cara, são... São coisas absurdas. Por isso que aqui eu quero focar no que eu tenho controle. O que eu tenho controle é eu sei quem são os caras que eu sigo e eu quero ver os posts deles. Fechou? Maravilha. Temos aí o Leonardo. Fala aí, doutor Leonardo. Opa, fala aí Wesley, beleza? Boa noite a todos. Wesley, seguindo ainda nesse raciocínio do do fan-out on-right, eu fiquei com uma dúvida aqui, como que a gente resolveu? Eu entendi bem a tua questão ali, bacana, mas eu fiquei com uma dúvida como que a gente resolver, eu entendi bem a tua questão ali, bacana mas eu fiquei com uma dúvida no seguinte não sei como que você trataria isso, se seria com TTL porque essas mensagens elas não podem ficar ali no Redis pra sempre, né, e a gente não tem como que faríamos o controle, por exemplo porque até onde eu entendi eu faria ali a escrita pra todas as pessoas que seguem uma pessoa, por exemplo, até que essa pessoa acessasse ali o seu Instagram e o Instagram fosse lá buscar as informações que tem para ela. Beleza, ela capturou aquelas informações de forma rápida ali do Redis, ela já leu. Só que, por exemplo, se ele tem mil seguidores, como que eu controlo se os mil já leram? Porque se eu usar a TTL, eu vou apagar isso aí depois de, sei lá, cinco minutos, sei lá, uma hora que seja. E quem não leu em uma hora vai ficar sem ler. Aí ele vai buscar no banco, nesses casos, como que a gente trata essa questão. E depois eu também tenho uma questão com relação à parte de upload dos vídeos aí, mas vamos um de cada vez. Tá, vamos lá. Cara, sobre essa parte de TTL, etc., na realidade tem um trilhão de estratégias que dá para utilizar e novamente isso acaba voltando um pouco em regra de negócio. Mas em via geral, você não vai colocar muitas vezes, eu acho, inclusive, pessoalmente, se você falasse agora para mim, Wesley, como que você faria? Primeira coisa, eu iria colocar um TTL alto, por padrão trabalharia sempre com TTL alto, mas eu setaria um limite máximo de mensagens no feed do cara, então eu vou dar um exemplo, eu falo que o cara pode ter pelo menos, vai ter 100 posts ali no feed dele pra ele ver ok? e deixo essas mensagens esses caras com TTL alto. Passou muito tempo, automaticamente esse cara vai embora. Não passou aquele tempo o suficiente e começou a entrar mensagem nova, o que que eu faço? Eu removo as mensagens mais antigas pra fora e fico com a 100 mais nova sempre. Então, essa é uma alternativa. Mas, novamente, a gente cai em questão de regra de negócio, entendeu? Quem tem que definir isso, provavelmente, é uma pessoa de produto. Entendeu? Tecnicamente falando, eu posso manter um TTL alto e ter um limite de mensagens. Esse limite, com certeza, tem que ser feito. Ou você pode trabalhar ali com TTL baixo. E ok, você vai ter menos mensagens ali, mas você vai ter muito mais cash miss, ou seja, você vai ter que bater muito mais no banco. E honestamente falando, cara, o que eu acredito do fundo do meu coração é que todas essas estratégias que a gente pode ter em relação à invalidação de cash, você só vai conseguir saber testando até você chegar a um número mais ótimo ali que vai conseguir equilibrar esse cache miss e esse cache hit que você vai ter. Existem também outras formas de invalidação que depois a gente pode trabalhar, mas por exemplo, a gente tem LFU versus LRU. Vocês manjam o que é isso? Não. LFU e LRU. LRU, tá? Ele significa Least Recent Used. Basicamente, são os dados menos utilizados recentes. O que isso significa? Vamos lá. A gente tem essa política de LFU, que são os caras mais recentes que a gente vai invalidar no cache. E a gente tem o cara de least frequently used. O que significa gente tem o cara de least frequently used. O que que significa? É o cara que é visto menos frequentemente. Quando a gente cai nesse tipo de situação, a gente cai no seguinte. Quando eu uso LRU, ele vai remover uma chave que foi acessada faz muito tempo, tá? E não interessa, ela pode ter sido vista um bilhão de vezes, tá? Mas se faz muito tempo que ninguém acessa, a gente vai invalidar esse cara. Soltei aquele vídeo viral, todo mundo viu, mas faz um baita tempo que pessoas acessam esse vídeo. Então eu mando ele embora. A gente tem o outro lado. A gente tem o frequente. O frequente, o que ele vai fazer? Ele vai remover a chave que foi acessada poucas vezes, mesmo que o último acesso tenha sido recente. Sacou a diferença? Então eu posso ter visto um cara que foi visto muitos poucas vezes, mas ela é vista recentemente, versus o cara que foi visto muitas vezes e não tem mais visita. Então, essas estratégias aí são, novamente, regras que você tem que testar e ver o que mais faz sentido no seu negócio. E por isso que é importante, novamente, a gente falar, galera, que a gente teve o nosso colega que falou, cara, a gente nunca vai desenvolver uma estratégia ou vai fazer um Instagram, trabalhar com isso. Cara, se vocês perceberem, estratégia de validação de cash, LFU, LRU, trabalhar com isso. Cara, se vocês perceberem, estratégia de invalidação de cash, LFU, LRU, trabalhar com TTL, cara, tudo isso aí são coisas que você pode usar diariamente no seu sistema e você não precisa estar trabalhando no Instagram da vida. Mesmo o fanout on read ou fanout on write, cara, acredite, você vai cair numa situação que às vezes não é usuário, mas você tem uma categoria de produtos que está relacionado com outros produtos e que tem muito acesso e você pode trabalhar exatamente dessa forma. Imagina no varejo, onde você quer trazer as coisas que mais façam sentido para aquele tipo de usuário na hora de trazer promoções. Então vocês conseguem perceber que não se trata de 100 milhões de usuários, se trata muito mais de estratégia e formas de pensar em como que um sistema pode ser feito. E aí a gente vai caindo cada vez em assuntos que acabam virando mais específicos. Por exemplo, que nem a gente acabou de falar, tem TTL, que é o tempo de valid nem a gente acabou de falar. Ah, tem TTL, né? Que é o tempo de validar de quanto aquele time to leave, o tempo que aquele registro vai ficar no meu cache. Mas eu posso ter um TTL alto, mas eu posso não trabalhar com TTL e remover sempre de alguma forma. Ou eu posso remover através de um worker de forma manual onde eu fico verificando os usuários online, crio toda uma inteligência e saio fazendo a minha limpeza manual no meu banco de dados. Também isso pode funcionar. Ou, novamente, você pode ter um sistema que manualmente fica removendo com TTL e ainda com outras políticas de invalidação. Sabe o que é bacana, Wesley? Nisso aí que você falou, vou até fazer um gancho aqui já pra qual de amanhã, né? Que isso tudo que você falou, eu acho que uma das coisas importantes que a gente tem pra tirar de lição é que não tem bala de prata. E se não tem bala de prata, tem que ter alguém pra pensar nessa lógica. E esse é um dos pontos que acredito eu que hoje ainda a IA não consegue tirar da gente. Cara, eu acho que sabe que é o ponto mais interessante de tudo isso em relação a IA? Não vou me aprofundar muito nisso, mas existem duas coisas. Uma coisa é, se você tá por trás e você é um arquiteto e tem que desenvolver o sistema e, sei lá, você nunca tinha ouvido falar em fan-out on read, fan-out on write, provavelmente você não saberia nem pedir pra IA criar uma solução dessa pra você. Sim. Partindo do princípio que você saberia e entender se fosse pedir pra IA criar essas coisas também pra você, você tem tantas opções como a gente acabou de falar que você também teria que conseguir guiar a IA e ir testando essas opções junto com ela entende? então pelo menos no momento que a gente tá hoje e não sei como vai ter daqui 5 anos e etc uma coisa pra mim é clara obviamente uma IA não conseguiria projetar essa parada sei como vai ter daqui 5 anos e etc uma coisa pra mim é clara, obviamente uma IA não conseguiria projetar essa parada testando e etc porque precisa realmente de um piloto aqui por trás e uma outra coisa que pra mim também é claro é que se você não exercitar esse tipo de coisa que a gente está vendo você também não consegue entre aspas, aprender isso diretamente com o Iá o que eu estou querendo dizer alguns provavelmente podem dizer que sim, alguns podem dizer que não, mas vocês acham que necessariamente tudo que a gente aprendeu e que a gente falou hoje em dia, simplesmente digitando no chat de GPT você conseguiria ter aprendido da mesma forma? é difícil, né? Porque você teria que saber esses conceitos, entender por onde que ele coloca. Então, é esse tipo de coisa que a gente tem que tomar cuidado com o IA, porque as coisas, elas não são binárias. Tem várias combinações, né? E cada arquiteto, cada pessoa tem uma experiência diferente, com um repertório diferente e provavelmente o Leandro já passou por situações que eu nunca passei, eu passei por outras situações e esse repertório é o que vai fazer com que a gente faça essas soluções se encaixarem, né? Para que provavelmente a gente defina, tome as decisões arquiteturais, defina as regras e, provavelmente, a IA vai codificar. Que a IA vai codificar, eu não tenho a menor dúvida, entendeu? Isso aí é claro e cada vez vai ficar melhor. Agora, esse tipo de coisa aqui, assim, se você não souber o conceito, é muito difícil você pedir pra IA fazer algo desse tipo. Entendeu? Eu acho que esse é o ponto. Código cada dia mais vai ser detalhe. Isso eu não tenho dúvidas. Agora, isso aqui é o que vai manter você no seu emprego, meu amigo. No final das contas, é isso aí que vai manter o seu emprego. Não vai ser a sua capacidade de programar mais. É, eu concordo. Esse é o grande ponto. Agora, quando a IA fizer isso, etc., aí eu já não sei mais o que a gente vai fazer da nossa vida. E detalhe, né? Quando a IA codifica, você tem mais tempo para desenvolver produto, né? Cara, com certeza. O jogo está mudando, a nossa profissão tá mudando, mas o ponto de reflexão que eu trago aqui pra todo mundo é um, você conseguiria aprender isso só olhando pro GPT pra você descrever o seu projeto pra ele programar pra você? E o segundo ponto é, será que você pedindo pra uma IA desenvolver sem você saber esses conceitos, ela conseguiria desenvolver de uma forma ótima ao ponto de você ter todas essas opções que você conseguiria trabalhar? Então, toda vez que você descobre algo que você nem sabia que você não sabia, você começa a perceber que você tem uma limitação que a IA não vai poder te ajudar porque você não sabe nem o que perguntar pra ela. Então, acho que esse aí que é um ponto que a gente sempre tem que tomar cuidado, galera. Pra gente não virar só refém de achar que você encontra tudo no GPTC. Ele vai tirar muito as suas dúvidas. E ainda ele não vai te chamar, ele não vai te julgar. Vai ser muito bom, eu uso pra caramba, mas quando você não sabe o que você não sabe você não consegue perguntar e aí vai limitar a quantidade de opções na hora de você fazer um sistema de design, por exemplo, por isso continuar estudando entender mais sobre Reds, entender mais sobre Cache, hoje a gente falou bastante de Fanout On Read, On Write são conceitos que são importantes e que eventualmente você vai precisar utilizar, independente se você estiver trabalhando na meta ou não. Em algum momento você pode precisar, é importante você saber que já existe mais alguma coisa. Não interessa se você não sabe implementar isso agora. Implementar novamente é um detalhe. Saber que o conceito existe é importante. Fechou? E tudo depende do contexto, aqui por exemplo a gente nem falou de throughput, então se a gente tiver um problema de throughput, de entrada de dados aqui que não dê conta de salvar por exemplo lá no Redis, todas as mensagens lá dos seguidores do Neymar como que a gente trata isso ainda? cara, vai ter, exatamente, vai ter que ter uma fila. Mas daí qual o tipo de cara? Como que eu consigo trabalhar? Aí tem a parte de regionalização, né? Por que que eu não posso ter um Redis mais perto do cara e esse Redis tem dados diferentes do Redis que tá lá em Singapura? Entendeu? As coisas, elas vão bem longe. Elas vão bem longe. E por isso que eu... Opa! As minhas luzes apagaram. Só um segundo, galera. Eu sei por que elas apagaram. Porque eu peço pra... Eu peço pra minha Alexa a... turn on... Isso é coisa da mulher, hein? Não, não é da... É da Alexa. É de uma mulher também. É que pra garantir que eu não esqueça as luzes acesas do escritório, eu peço pra ela desligar sempre esse horário, porque daí eu às vezes esqueço. Eu tenho iluminação, essas coisas, daí dá ruim. Viu, Wesley? Eu tô um pouquinho cru ainda do IA. Eu tô correndo atrás, tô vendo todas essas questões de documentação, mas o que eu sinto é que pra IA Editar Um projeto que já está em andamento É muito mais difícil do que ela Criar um projeto todo do zero Com uma base de documentação muito bem feita Cara, tudo depende Amanhã a gente vai falar Sobre isso, tá? Mas eu digo pra você que é mais ou menos Mas junta Esse ponto que eu botei agora com isso que a gente está vendo hoje, que é um tipo de documentação que eu vejo mais nessa linha do XP, de fazer uma documentação mais ágil, de entrar dentro dessas questões de metodologia ágil. E me parece que a metodologia antiga, que era mais engessada que era em cima das uml que era tipo né fazer o caso de uso fazer toda aquela documentação pesada que tinha antigamente para construir um sistema já do início ao fim com todo tá dia de agrama de custo de peso de não sei o que de conta de função então todas as coisas parece que o lar hoje em dia, pra IA É muito melhor do que Documentação ágil Cara, hoje a gente chegou num momento que Eu pensei que a gente voltou um pouco Cara, melhorou muito A gente vai falar disso amanhã Segura a onda Mas o meu link Era mais pra voltar aqui Então, mas Essas documentações que hoje a gente está vendo aqui, né, de System Design, ela começaria mais ou menos aonde e terminaria aonde? Tipo, seria mais se focar mesmo em identificar os... O System Design aqui nesse caso, ele termina... E os atores e as ações que têm que ser feitas dentro dos requisitos? O system design, que é esse que a gente está fazendo hoje, ele acaba. Quando eu conseguir garantir que os meus três requisitos funcionais estão prontos e que esses requisitos não funcionais também sejam cumpridos. Aí eu acabei meu system design. Por exemplo, eu vou dar um exemplo aqui pra vocês. Baixa a latência pra exibição de imagens e vídeos. O que que acontece aqui? Eu tenho o meu bucket, certo? Então quando o meu usuário, ele precisar baixar uma imagem, da forma como está hoje, o que que eu tenho que fazer? Ele vai ter que baixar a imagem, o vídeo, aqui no bucket da S3. Mas o bucket da S3 está numa localização. Se ele estiver nos Estados Unidos, e eu estiver no Japão, se eu estiver no Brasil, eu vou ter que ir até lá e eu vou ter uma alta latência para fazer isso. Como que eu posso, por exemplo, facilitar esse tipo de coisa para que eu posso, por exemplo, facilitar esse tipo de coisa para que eu tenha esse requisito não funcional resolvido aqui para mim. Baixa latência, imagem e vídeo. Esse é um outro conceito, não é nem conceito, é um conceito, mas é algo materializado no final das contas que a gente tem CDNs, né? Que é Content Delivery Network. A CDN, o que ela consegue fazer no final das contas é que o usuário final, toda vez que ele quer uma imagem, um vídeo ou qualquer coisa, ele bate na CDN. Essa CDN, na realidade, ela disponibiliza essas imagens em vários lugares do planeta, em vários, a gente chama de POPs ou zonas de distribuição, no planeta, depende do provedor de CDN que você contrata. Então, quando você vai bater aqui na CDN e não achou, o que acontece? A CDN vai lá, bonitona que nem um cache, e bate no seu bucket e carrega aqui então a partir de agora eu sempre vou pegar as minhas imagens, os meus vídeos mais próximos da onde eu tô tá, e isso aí já muda o meu jogo já matei uma outra um outro ponto ali do meu requisito não funcional, agora eu consigo baixar pra caramba a minha latência no máximo e daí vai depender muito da qualidade da minha CDN. Eu como desenvolvedor fazendo o meu system design, eu sei que eu cumpri esse meu requisito. Ou seja, eu estou trabalhando com CDN onde eu consigo pegar essas informações aqui comigo, tá? Fez sentido isso pra vocês? Sim. E eu posso baixar também só o início de cada vídeo, por exemplo, né? Ou baixar uma imagem inicial menor. Tem várias estratégias, né? Que dá pra fazer pra carregar a página todo primeiro. Normalmente quando ele converte, normalmente quando o vídeo converte, ele é convertido num formato onde ele tem diversos segmentos, e daí na hora que começar a carregar, ele não carrega tudo, ele vai carregando aos pouquinhos então, assim novamente a gente consegue fazer a galera que tá no nosso MBA, só pra vocês saberem, a gente fez o System Design da Netflix, um tempo atrás e a gente falou bastante sobre essa parte de imagens, de vídeos CDN, a gente falou bastante sobre essa parte de imagens, de vídeos, CDN, a gente falou de Media Converter, a gente falou de Pipelines, a gente falou de bancos de dados. Depois eu até dou uma palhinha aqui para vocês. Mas, por exemplo, esse daí também entraria num design system já mais aprofundado, já mais, digamos assim, bem mais lapidado. Em relação ao tipo de imagem? Com o pre-upload do vídeo, de tantos segundos? Não, não, não, porque, cara, isso é padrão de mercado, tá? Você converteu o vídeo, ele já entra num formato, ou é no MPEG-DASH, ou ele é um formato HLS, e por padrão, esses vídeos já trabalham isso. A CDN entraria, essa outra estratégia seria uma estratégia de negócio? É, seria uma estratégia de negócio ou alguma especificidade, por exemplo você tá numa entrevista, o cara perguntar pode perguntar, como que funciona um media converter? Aí você pode entrar e falar assim, ó cara, isso aqui vai ser um pipeline que o vídeo vai chegar, aí vai acontecer isso, depois que converter isso, ele vai converter. Depois que ele converter, a gente vai subir. Depois a gente vai ver se esse vídeo é do Cristiano Ronaldo. Se for, a gente já bota ele direto na CDN para garantir que a gente nem vai ficar batendo em algum momento num bucket para pegar essa informação. Aí, cara, novamente, se a gente for olhar só feed service e a gente botar uma lupa aqui, vai para um outro momento, entendeu? Se olhar só para o media converter, vai para um outro... É tudo uma questão de zoom aqui. Em relação a system design, baseado no que a gente está trabalhando aqui, a nossa ideia é conseguir ter essa visão macro, fazendo com que esses requisitos não funcionais sejam cumpridos. E hoje é, basicamente, disponibilidade em relação à consistência. Sim, a gente vai ter mais disponibilidade, porque nós estamos sempre online, vamos dizer assim, mas não necessariamente eu vou estar consistente. Se eu tivesse que estar consistente, significaria que toda vez que o Cristiano Ronaldo fizesse um post, todo mundo só poderia ver o post dele quando todo mundo tivesse no feed Cristiano Ronaldo. O que não faria sentido nenhum. Então, a gente preza por disponibilidade ao invés de consistência. Um ponto importante também lembrando é que o seu sistema não precisa ser 100% disponibilidade ao invés de consistência. Um ponto importante também lembrando é que o seu sistema ele não precisa ser 100% disponibilidade acima de consistência, ele pode ser híbrido. Tem parte do seu sistema que você precisa de consistência, tem parte do seu sistema que você precisa mais de disponibilidade. Desculpa atrapalhar de novo. Nesse caso às vezes para ter uma latência um pouco menor, talvez não seria interessante fazer um sistema de ranqueamento de relação... Fazer como se fosse um usuário relacionamento N para N, com o usuário mesmo. E os meus usuários que eu sigo, ter um sistema de ranking dentro dele e depois eu posso até enlouquecer e fazer esse sistema de ranking dentro dele e depois eu posso até enlouquecer e fazer esse sistema de ranking ali conectado com outro sistema de running, sabe, um data warehouse Novamente, cai em regra de negócio pra um feed service Vai pra um feed service aí você tá colocando uma lupa nesse cara, aí dá pra fazer um system design do feed service Entendeu? Novamente, é uma questão de lupa. Olhando aqui, cara, eu sou extremamente direto. O usuário tá criando um novo post? Tá. Ele tá conseguindo seguir o outro? Tá. Ele tá tendo acesso ao feed? Tá. Ele consegue lidar aqui com 100 milhões de usuários por dia, baseada nessa arquitetura? Partindo do princípio, tá? Que esse banco de dados tá sendo gerenciado pelo MWS da vida, ou tá trabalhando com DynamoDB, que também ele é autoescalável. Que eu tô trabalhando com Reds em múltiplos shardings. Que eu tô trabalhando com Fila, que permite que eu consiga um alto throughput aqui para mim, que eu tenha que esses serviços, eles consigam escalar horizontalmente, eu consigo subir esses vários serviços de uma vez aqui, ou seja, ele consegue ir escalando esses caras. Esse meu API Gateway, ele consegue dar conta dessa entrada? Sim, ele consegue com certeza ajustar e conseguir aguentar milhões e milhões de usuários. Aí é uma questão muito mais de infraestrutura. Quando a gente fala em aguentar uma pancada de usuário, o ponto principal que você tem que se ligar é, eu consigo trabalhar de forma síncrona pra evitar diversos tipos de problema, né? Eu consigo fazer com que os meus serviços eles consigam escalar, né? E eu consigo fazer com que os dados que eu esteja trabalhando, eles também consigam ficar de forma escalável, tá? Então, esse tipo de coisa é algo que acaba trabalhando pra gente. E aqui, vai da mesma forma. Medium converter, escala. API gateway, cara, vou dar um exemplo. Você pega AWS API gateway, cara, vou dar um exemplo. Você pega a AWS API Gateway, ponto. Ela toma cuidado para você, para conseguir segurar todas as suas requisições. Ah, eu vou usar a minha API Gateway, ok. Eu vou pegar uma API Gateway conhecida, uma marca de API Gateway, um Kong da vida, e eu vou conseguir replicar e horizontalizar esses caras. Principal ponto, você falou em escalabilidade, você tem que pensar que todos os seus serviços têm que conseguir escalar de forma horizontal e que as principais operações que são necessárias, elas têm que conseguir rodar de forma assíncrona. Por exemplo, esse follow aqui, ele está simplificado, mas ele poderia sim cair diretamente no follow service dentro de uma fila de operações e coisas desse tipo, tá? Mas eu acho que a mensagem principal, vamos dizer assim, desse nosso system design é eu consigo escalar horizontalmente todos os meus serviços, eu consigo distribuir os meus vídeos e imagens para o mundo inteiro, eu consigo ter uma forma mais ótima de ter uma latência super baixa utilizando o cache e com estratégias que acabam fazendo sentido. Eu consigo lidar com uploads de grandes vídeos e né, e de qualquer tipo de mídia, né, e consigo também fazer a conversão desse tipo de mídia pra que ela fique no tamanho adequado pra minha aplicação. Baseado nisso, galera, é... Eu digo que, cara, eu concluí o meu System Design. Entendeu? Que eu acho que são os pontos mais tricks que você acaba tendo, sei lá se fosse fazer uma entrevista de system design provavelmente, no caso de Instagram, eu não acho que seria, não teria coisa depende muito do entrevistador é claro, mas eu não acho que teriam coisas tão, tão diferentes do que a gente acabou de colocar, mas se você olhar, é complexo. Ele não é um system design simples como alguns que a gente acaba vendo. Como criar o encortador de URL, entendeu? Não, ele entra muito o conceito de cache, essa parte de URL pré-assinada, CDN... Os protocolos de comunicação entrariam dentro do System Design? Cara, nesse caso aqui, não entraria. Aqui eu estou colocando que eu estou trabalhando com uma fila. Eu não estou falando se eu estou trabalhando com a MQP, eu não estou falando se eu estou trabalhando com Kafka, etc. Porque depois a gente começa a entrar em qual é o tipo da tecnologia que a gente vai entrar. Normalmente, o que é colocado, normalmente, é banco de dados, normalmente, o tipo do banco de dados, tá? Eu coloquei aqui Postgres, porque normalmente, para banco de dados relacional, para cargas bem pesadas, o Postgres, ele já é um cara que, normalmente, ele tem bastante recurso que ele vai conseguir te ajudar, porque ele tem diversas extensões, tá? Não que o MySQL não funcionaria. O Instagram rodou, não sei quantos anos rodando com o MySQL. Ele hoje usa o Postgres pra caramba como um dos bancos de dados principais e usa a Cassandra pra caramba. Na realidade, eles reescreveram o Cassandra resolvendo alguns outros problemas que o Cassandra tinha. Então, assim, essas paradas vão muito longe. O ponto principal mesmo aqui é a gente conseguir entender essa ideia de como criar um system design a gente não entrou galera em plano de capacidade porque se a gente entrasse ia ser mais uma hora pelo menos aí pra gente conseguir trabalhar mas espero eu que vocês tenham conseguido curtir e ter gostado essa dinâmica do dia de hoje curtiram galera? é tarde né? 11 e 15 no Brasil pra mim é 10 e 15 aqui nos Estados Unidos curtiram galera? muito bom mesmo parabéns aí cara bacana, deu pra pegar bastante conceito novo né? muito mais é galera Parabéns aí, cara. Bacana, deu pra pegar bastante conceito novo, né? Mais. É, galera. Essa parada... Tô doido pra fazer esse MBA aí com você, cara. Cara, vamos lá, novamente. Eu não posso deixar de fazer o Jabá, você tava até esquecendo. Galera, temos o MBA em Arquitetura Full Cycle. Ele é reconhecido pelo MEC. A gente tem uma faculdade chamada Faculdade Full Cycle de Tecnologia. As aulas que a gente vai ter agora nesse MBA, ele vai começar em junho, tá? Mas a gente tá com pré-matrículas abertas, onde você pode ter até 3 mil reais de desconto, tá? Então, nesse MBA a gente foca muito em arquitetura de solução, inclusive a gente tem matérias específicas só para, quer ver, se eu pegar aqui, fundamentos de arquitetura de solução, system design e design docs, para quem estava falando em documentação e etc. Como é que funciona system Design e Design Docs? E a gente foca bastante também em fundamentos de arquitetura de solução. A gente tem parte só de banco de dados, a gente tem só de Apache Kafka, a gente tem de Cloud Computing e Serverless, a gente tem parte de Edge Computing. Aí para arquitetura de software, tem fundamentos de arquitetura de software, Domain Driven Design, Solid e Design Patterns, Arquitetura Hexagonal e Clean Architecture. Temos também até participação do LSTAR Coburn, que é o criador da arquitetura hexagonal. Ele deu a talk para a gente, foi bem bacana também. A gente tem áreas só de microserviços e arquitetura baseada em eventos. E aí toda a parte de DevOps, SRE, com containers e Kubernetes, fundamentos de DevOps, SRE, Infra-Scode e observabilidade. E aí, claro, que a gente tem a parte de soft skills, que é a parte liderança de trabalho e equipe, marketing pessoal, para você ser visto dentro e fora também da sua empresa, e empreendedorismo. E isso muda completamente a forma de inclusive como você trabalha ter algo que a gente chama de intraempreendedorismo quando você consegue empreender até no seu local de trabalho, onde vai te dar mais chances aí de promoção e crescimento profissional, tá? Então esse nosso MBA aqui cara, ele é bem completo é um dos nossos carro-chefes. Tem gente muito forte que dá as talks pra gente. E, galera, a gente tem sessões semanais muito parecidas do que a gente tá fazendo aqui. Então a gente tem sessões de breakout rooms. A gente tem sessões que a gente traz um especialista. O último que veio foi o Elemar Jr., por exemplo. Onde ele falou bastante, inclusive sobre essa parte de IA a gente tem sessões de laboratórios, onde a gente dá um desafio pra vocês e depois vocês trazem e a gente discute esse desafio, eu resolvo esse desafio e, obviamente, as aulas não são só comigo, tem muita gente boa aí por trás, então a dica que eu dou pra vocês agora, nesse momento, é entrem nesse link, tá? E nesse link, como que eu coloco pra everyone? Ô, Leonan, coloca pra mim, por favor, que eu não tô conseguindo colocar aqui no... Galera, vocês preenchem esse link, a nossa equipe vai entrar em contato com vocês e vai entender o seu momento profissional. O que isso significa? Pra ver se nesse momento faz sentido você participar. Se você tem pré-requisito, se você qual é a sua disponibilidade de tempo, a sua disponibilidade financeira, tá? Então a gente vai entender realmente se o MBA faz sentido no momento que você tá aí na sua carreira. É um bate-papo totalmente sem compromisso, a gente vai explicar o programa para você, tudo bonitinho, mas o ponto que a gente sempre está visando focar e é algo que a gente está reconstruindo ao longo do tempo nesse MBA, que é, antes a gente focava muito em conteúdo gravado e nós temos conteúdos gravados fantásticos que é antes a gente focava muito em conteúdo gravado, e nós temos conteúdos gravados fantásticos que é a base de todo o MBA mas o que a gente acredita hoje em dia é que essa pessoalidade que a gente está tendo aqui é diferente, e é por isso que a gente tem agendas bem claras de todas essas participações ao vivo essas interações que a gente tem a gente tem sessões de mentoria também, que você entra, tira suas dúvidas, pode ser dúvida técnica, dúvida de carreira. Então, a gente tem todos esses encontros que faz com que não seja apenas um curso que você vai assistir aula, assiste um vídeo e faz uma provinha. Um ponto importante é que, independente se você é formado ou não, você pode fazer esse MBA se você é formado, você vai receber um certificado validado pelo MEC de Lato Senso e se você não é formado, você vai receber um certificado de extensão universitária pela nossa faculdade um certificado reconhecido também então, independente se você está formado ou não você pode fazer o MBA com a gente. Não é apenas para quem tem formação. E se você ainda está cursando a faculdade e o seu MBA acabar antes, a gente emite o certificado de extensão universitária e quando você se formar, a gente cancela esse certificado e emite o de pós-graduação para vocês. Então, isso aí é super importante também pra vocês também tomarem as decisões, tá? Então, preenche esse form tá? Cara campo simples que você preenche, a gente marca um horário, faz um bate-papo com você e aí você vai ter um belo desconto também pra poder participar nessa turma aí com a gente, fechou? Maravilha, galera? Então, pessoal, queria dar muito boa noite. Valeu por vocês todos estarem aqui até agora. Fico mega feliz de saber que tem bastante gente aqui. E amanhã, no mesmo horário, a gente vai falar bastante sobre comunicação entre sistemas, a gente vai falar sobre protocolos e etc. E também a gente vai falar sobre protocolos e etc, e também a gente vai falar um pouco também sobre inteligência artificial. Tá? Então, não percam amanhã, 7 horas da noite, vocês vão receber o link aí também pra vocês poderem participar, e eu quero ter um bate-papo bem bacana aí com vocês, e espero que vocês estejam curtindo aí esses dias. Maravilha, galera? Maravilha, galera? Maravilha. Obrigado pela disponibilidade, Wesley. Até pelo horário aí. Obrigado. Demais, demais, cara. Legal pra caramba. Cara, velho, se tem uma coisa que eu amo fazer na minha vida é isso, cara. Então é top fazer e saber que de alguma forma tá ajudando a galera, entendeu? Independente se você é aluno ou não é aluno. Tem conceitos que a gente aprende e que a gente acaba levando pro resto da nossa carreira. E eu acho que esses tipos de oportunidade fazem com que a gente conheça gente que a gente não conhecia, com essas dinâmicas, e aprendam coisas que estejam às vezes um pouco fora da nossa bolha, né? Então, espero que estejam, às vezes, um pouco fora da nossa bolha, né? Então, espero aí que vocês estejam curtindo e a gente se vê amanhã, cara, porque hoje só foi o primeiro dia. Tem mais coisa aí pra ver. Maravilha?