Então, eu vou compartilhar a minha tela, eu vou tentar seguir uma linha de raciocínio que eu recomendo que, por exemplo, em uma entrevista vocês sigam. Vai depender muito dos entrevistadores, de como que eles gostam de conduzir. Padrão de Big Tech, de forma geral, é mais ou menos o padrão como eu vou trazer. Algumas têm alguns momentos um pouco mais simplificados algumas querem algo um pouco mais detalhados então é mais ou menos o método como a gente acaba trabalhando aqui, mas tem diversas variações e tudo mais basicamente o método que a gente segue é uma forma que eu já consegui falar com muita gente, na realidade, que entrevista a galera com System Design, galera do Mercado Livre, de bancos também. Tem também a galera da Microsoft, tem também aquele nosso professor que também dá aula de System Design, que é o Fabian, quem nunca teve aula, acessou os vídeos deles, também ele especializa nessa parte de System Design. Então, normalmente, a gente segue meio que esse método que assim, ele é bem parecido ali padrão de mercado de como que as coisas colocam, tá? Pra gente não gastar, vamos dizer assim, muito tempo um monte de desenho, algumas coisas eu trouxe prontas pra não ter que ficar digitando, ainda mais muitos dos requisitos do que a gente coloca, eu também já deixei ali no Scaledraw. Então, deixa eu colocar aqui e torcer para não dar ruim. Está com todo mundo conseguindo ver aqui minha tela? Eu vou ter que aumentar o zoom provavelmente, mas é importante que vocês consigam ver aí minha tela de boas vou aumentar o zoom o zoom eu tô sabendo, até pra mim tá pequeno, tá? show de bola galera, o negócio é o seguinte, tá? eu só não coloquei o título aqui, mas vocês como muitos bons alunos que fazem as aulas, vocês sabem que hoje é dia de Netflix, tá? E a nossa ideia é a gente conseguir criar o System Design aí de uma Netflix, tá? Então, tem alguns pontos importantes que eu quero alinhar aqui com vocês, inclusive em relação às expectativas, tá? Normalmente, quando você cai nesses tipos de sessão, ou imagina que você fosse fazer uma entrevista na Netflix, com certeza a entrevista deles, em algum momento, ia cair coisas referentes a vídeo, a player, a CDN, mais ou menos como o nosso amigo William falou, que quando ele vai entrevistar provavelmente gente no banco ele acaba fazendo coisas que tem mais referência ao domínio que ele trabalha sei lá, saldo, extrato e coisas desse tipo tá? então o ponto principal aqui não é o quanto a gente entende de vídeos em si mas sim de como que a gente acaba pensando necessariamente nas soluções. Por exemplo, eu já trabalhei bastante com vídeo, tá? Mas eu não sou um cara especialista, super especialista em vídeo que entende todos os detalhes dos principais codecs e etc. Mas dá pra ter um pouco de noção de como que os vídeos funcionam. Então a nossa ideia hoje aqui é além de a gente fazer o System Design, a gente vai acabar invariavelmente falando de algumas outras tecnologias e até mesmo de bancos de dados, por exemplo. Fechou? Então vamos lá, galera. Entendimento do sistema. Então a primeira coisa que quando vocês pensam aí numa Netflix, um sistema desse por padrão, ele tem alta leitura ou ele tem alta gravação? Essa é uma pergunta ali que a primeira coisa que vocês tem que pensar no final das contas é isso, porque isso muda completamente a forma de como que você vai desenhar o sistema, desde persistência, bancos de dados, cache, como é que você vai desenhar o sistema desde persistência bancos de dados, cash como é que você vai atender as transações como que você vai escalar o sistema e etc então eu acredito que muitos de vocês provavelmente espero que todos vocês na realidade tenham colocado que é um sistema de alta leitura. Provavelmente, a gente deve ter muito mais gente assistindo o vídeo do que alguém cadastrando o vídeo ou fazendo muitas coisas. Provavelmente, o tempo que a gente passa lendo, consumindo dados, provavelmente, ele é maior. Num contexto de sistema, o que é mais importante a que vocês acham na Netflix? Consistência ou disponibilidade? E essa pergunta é uma das perguntas principais que vão sempre aparecer para você. Normalmente, quando a gente está falando disso, a gente está falando de teorema CAP, e no final do dia, ele sempre vai falar, você quer manter dados consistentes ou você quer deixar a consistência um pouco de lado e garantir disponibilidade, tá? E tem uma diferença muito grande entre esses dois pontos, tá? Por exemplo, vamos falar do Bradesco, já pensou que interessante, eu fui lá no caixa eletrônico e eu vou falar, eu quero sacar um milhão de reais. Mas como não tem consistência nos dados, o meu saldo talvez ali naquele momento esteja errado, porque não está totalmente sincronizado. Aí o que vai acontecer? Eu vou conseguir sacar mais dinheiro do que eu tenho em conta. Imagina que eu tenho essa situação. Imagina que eu tenho essa situação. Então, muitas vezes, numa situação assim, eventualmente é melhor travar e deixar indisponível o recurso de saque, já que eu não tenho um dado consistente, do que deixar esse dado disponível e eu sacar dados de forma errada. Então, isso é um caso claro. Mas, por exemplo, vamos imaginar numa Netflix. Vamos imaginar que no sistema de recomendação, ele ainda não terminou de consolidar se esse filme é 4 estrelas ou 5 estrelas para você. Você vai esperar com que aquele filme termine de processar essa informação, para daí você deixar ele disponível para acesso, para aparecer para você, ou você prefere que mesmo que todo aquele algoritmo, por exemplo, de recomendação que apareceu, não esteja completo, mas ainda assim você tem acesso ao filme. Então, claramente, é melhor eu ter acesso ao filme mesmo que, às vezes, aqueles dados não estejam sendo inteiramente trazidos pra mim por exemplo, eu vou ver as discussões num fórum de discussão às vezes tá aparecendo ali 501 respostas eu prefiro ter o que? conseguir acessar o tópico sem saber a quantidade exata de respostas ou é melhor eu só poder ver aquele tópico quando tiver todas as respostas computadas? Então, perceba que normalmente isso é uma decisão de negócio. É uma decisão de negócio. Mas, obviamente, que numa situação como essa, dá para a gente começar a imaginar o que cada empresa prioriza. Então, tem situações realmente que consistência é importante. Um sistema de compra de ingressos. Eu não posso vender ingresso para duas pessoas no mesmo lugar. O banco, eu não posso sacar mais do que eu tenho. Provavelmente, em bancos também, há casos que a consistência, às vezes, talvez não seja tão forte quanto a disponibilidade. Posso estar até enganado, mas às vezes o meu saldo tem um gap, sei lá, de um segundo é aceitável para não deixar saldo indisponível. Então, não está batendo com o extrato. Vai depender muito de como que o William e a galera do banco um dia vão dar uma aula para a gente. Mas dependendo, um banco pode, dependendo, não sei como é que funcionam as regras, esses dados terem uma consistência eventual. Mas o ponto importante aqui, a gente vai de disponibilidade. Agora, requisitos funcionais e suporte features primeira coisa que é interessante quando você cai numa sessão de system design a gente pode ter duas situações uma situação é quando de forma geral a pessoa vai perguntar para você, na Netflix, na sua cabeça, quais são recursos que não podem faltar? E a segunda pergunta pode ser, quais recursos que vão ajudar esses recursos principais a funcionarem? Então, vocês vão ter as duas situações. Uma, onde essas core features, essas support features, elas já vão vir especificadas, ou vão ter casos que a gente pode perguntar e fazer uma reflexão clara do que a gente acha que tem que ter e do que a gente acha que não deve ter, por exemplo, ali num sistema em relação a isso. E isso para a gente é muito importante no final das contas, por quê? Porque a gente sabendo as features que a gente vai colocar aqui, isso aqui vai definir exatamente o escopo do nosso System Design. Então se você enche de features aqui, você vai ser obrigado a cobrir todas essas features o tempo todo. E aí você pode, como que eu posso dizer, se complicar no meio de uma entrevista, no meio de uma sessão. Então sempre tente colocar o mínimo de features possíveis, mas que não impeçam. Que vocês consigam explorar. Legal? Então na opinião de vocês. Quais features. Que a gente tem que ter. Para uma Netflix rodar. Mínimas. Core features mesmo. O ponto de vista de vocês. Podem falar. O microfone. Streaming de vídeo, assistir vídeo vamos lá playback de vídeos o que mais? catálogo cadastro pesquisa de tema opa catálogo, pesquisa então você acha que a Netflix selogo, pesquisa. Então você acha que a Netflix, se não tiver pesquisa... Não, o Core não. Se não tiver pesquisa, é procurar na lista, sim. Opa, então vamos lá. Então vamos colocar aqui pesquisa, algo importante. Mas ela... É suporte. Ok. Eu colocaria também a parte de pagamento porque sem o pagamento fica difícil vamos lá suporte features ajuda você a entrar e conseguir utilizar mas core features, o domínio da empresa a Netflix é uma empresa de vídeo o que eu preciso galera pra conseguir fazer um vídeo tocar? Sempre pense no mínimo possível. Tem que ter o vídeo stories, tem que ter o lugar de guardar o vídeo. Não, mas pensa na feature, não pensa no armazenamento. Upa, então, ó, matamos as core features aqui, ó. Upload de vídeos. Eu preciso poder fazer o upload dos vídeos e eu preciso tocar os vídeos. Ok? Então, isso aí são pontos, assim, extremamente claros. Se eu não puder fazer o upload, eu não consigo tocar. Se eu não consigo tocar os vídeos, ninguém consegue assistir. Legal? Agora, a busca de vídeos é um recurso super importante, realmente, Agora, a busca de vídeos é um recurso super importante realmente que a gente pode ter em relação à parte aí do playback. Leonan, qual outra feature de suporte que a gente pode ter aqui, cara? Pode ser a de recomendação. Pode ser uma feature de recomendação. Que mais, galera? Gateway de pagamento. Gateway de pagamento. Pode ser uma feature de pagamento. Gerenciamento de perfil. Perfis, né? Categoria dos vídeos. É o IAN, né? O IAN. Avaliação dos vídeos. Se gostou, se não gostou. Legal. Então, o seguinte. Recomendação. Olha só, eu quero que vocês comecem a pensar o seguinte agora, para todo mundo ficar esperto, tá? Falei recomendação de vídeos. O que que vão perguntar de cara para vocês em uma entrevista em System Design? Como é que funciona a recomendação? Como é que é feito esses algoritmos? Como é que funciona a recomendação? Como é que é feito esses algoritmos? Você tem uma precisidade de máquina? Como é que você pega as preferências do cara? Quem manja aqui de dados pra caramba? Se você não manja isso, você já se enforcou na entrevista. Você entendeu? Isso aí que vocês têm que tomar muito cuidado, tá? E eu não estou dizendo que colocar esses tipos de feature não seja legal, tá? É legal. Mas toda vez que você ousar a colocar qualquer coisa, principalmente em feature... Porque dessas aqui você não escapa, concorda comigo? Sim. Agora, aqui eu consigo escapar. Algumas coisas eu consigo escapar. Se eu colocar um sistema de recomendação, quem aqui já participou de realmente fazer sistemas de recomendação de vídeos, de qualquer coisa aí? Se você já tem experiência com isso, esse aí é o momento de você brilhar. Concorda comigo? É um super momento de você conseguir brilhar. Agora, se você nunca trabalhou com isso, tente sempre pensar algo que você já fez no passado e que talvez consiga te ajudar a trazer mais pontos importantes aqui. Eu vou colocar uma ficha de algo que eu já fiz, tá? E não tô dizendo que eu sou especialista, mas eu minimamente consigo responder algumas coisinhas. Tem uma identificação de lançamento em novos vídeos? Tem uma que a gente pode utilizar, Wesley, que é a DRM, né? De pirataria, recursos de pirataria. Isso, então eu vou colocar aqui DRM, porque eu já trabalhei com DRM no passado, já tive uma experiência sobre isso. Só para vocês saberem, DRM significa Digital Rights Management. Digital Rights Management. É para conseguir minimizar a pirataria. No final das contas é isso. Management. É uma forma. Então, eu perceba, eu estou tentando ao máximo diminuir a quantidade de coisas que eu coloque aqui. Quanto menos coisas eu colocar, para mim é melhor. Mas, se você está sendo entrevistado, você sempre vai ter que fazer combinados com a pessoa que está te entrevistando. Senão você vai colocar uma feature, cara, mas só isso. Então, normalmente você faz combinados da seguinte forma. Olha, eu vou trabalhar com essas features aqui, inicialmente. Eu acho que isso aqui também é importante. Provavelmente tem mais coisa, mas vamos usar isso aqui como ponto de partida e daí durante o processo a gente pode explorando mais. Sempre tente fazer combinados no meio da conversa exatamente para alinhar as expectativas e todo mundo está na mesma página. Então, da mesma forma que você falaria para o entrevistador, eu estou fazendo isso com vocês. Vamos focar nesses quatro pontos, galera? Eu consigo fazer o vídeo, eu consigo fazer o upload, eu consigo buscar, que é algo super importante, e eu consigo proteger os meus vídeos com direitos autorais, por exemplo. Ok? Nesse caso, então, a gente não precisaria se preocupar, por exemplo, com o acesso do usuário à plataforma? Login, cadastro, esse tipo de coisa? Cara, isso aí, qualquer sistema de design que você colocar, login, cadastro, caras, isso aí assim, todo mundo já parte do princípio que isso já existe. A não ser que, por exemplo, você vá fazer uma entrevista para uma empresa de API gateways, que um dos super recursos importantes de uma empresa dessa é a parte de autenticação. Então, isso faz parte do domínio dela. Então, minimamente, você vai se preocupar com isso. Agora, de forma geral, uma coisa que eu diria claro aí para vocês, vocês vão falar em System Design, tente ao máximo sempre esquecer a autenticação, a autorização, a não ser que seja muito importante para aquele domínio que você esteja falando. Por exemplo, o Netflix. Cara, é óbvio, todo mundo tem que contratar Netflix, pagar Netflix, cara, é óbvio, todo mundo tem que contratar a Netflix, pagar a Netflix, fazer assinatura pra conseguir entrar. Mas se você olhar bem, a Netflix é um sistema que é totalmente baseado em vídeo. Então é aí que a gente sempre tenta explorar, tá? Mas por padrão, assim, de forma geral, eu já ignoraria totalmente qualquer coisa desse tipo de autenticação e coisas desse tipo, a não ser se isso vai cair ali na entrevista. O pessoal pode perguntar, como que funciona a autenticação? Aí, você vai caindo por diversas formas. Aonde que ela vai ser? Você vai ter um sistema de autenticação? Você vai ter um banco de dados? Você vai utilizar algum API Gateway? Você vai ter um banco de dados, você vai utilizar um algum API Gateway, você vai usar um serviço de autenticação, um QLock, um serviço em cloud, incógnito, ou qualquer coisa desse tipo, tá? Mas normalmente esses recursos que tem tudo quanto é sistema, não é isso que vai fazer o seu sistema de design brilhar. Você vai falar authentiquei, ponto. Basicamente é isso. Fechou? Fechou, não entendi. Beleza. Maravilha. Então, tudo que for meio óbvio, vocês já meio que ignoram sempre, tá? Sempre tentem pegar aquilo que tá muito mais na veia pra ser explorado, né? Então, tem tanta coisa pra explorar de vídeo, a gente não botaria uma autenticação no meio da história, tá? Agora, se você fosse fazer uma entrevista pra trabalhar no Paypal, no Pagar.me, provavelmente, né, colocar coisas de meios de pagamento faria mais sentido. Então, depende muito da onde que você, de qual contexto que você tá ali naquele tipo de entrevista, tá? Ô Wesley, então no caso ali a busca também não seria muito óbvia não, pra esse contexto? Cara, se você pensar bem, a melhor forma que você pode ter pra encontrar um vídeo pensa assim, ó, na utilização do usuário, na Netflix coisas que eu preciso muito preciso, pra eu assistir vídeo eu preciso encontrar os vídeos, tá? então essa é uma super feature importante agora perceba normalmente essas features de suporte elas ajudam o domínio funcionar melhor, qual que é o domínio que a gente tem? no caso, é assistir vídeos, tá? A pagamento é uma feature de suporte? Ela é, pra pessoa poder acessar a plataforma. Mas, concorda comigo que a gente tá falando de uma Netflix, a gente tá falando de muitas coisas pra ajudar o domínio. Na real, o pagamento, nesse caso, acaba sendo, entre aspas, uma daquelas coisas que acabam sendo bem óbvias, como login, contratar, a gente já tenta partir do princípio, mas novamente, se você está num outro contexto, num outro system design, onde a parte de pagamento, ela brilha, aí nesses tipos de caso, eu acho que vale a pena. Agora, por exemplo, search, um catálogo organizado, busca por categorização, todos esses tipos de coisas são, assim, recursos super importantes pra dar suporte pra que esse cara funcione bem. Tá? Então, tenta sempre pensar em coisas correlatas. Fechou? Fechou, obrigado maravilha, e lembrando galera não existe uma verdade absoluta, isso aqui você coloca de forma arbitrária e sempre vai conversando com o entrevistador, por exemplo se alguém colocasse pra mim nesse momento falasse por exemplo, ah, pagamento se eu fosse um entrevistador, eu colocaria cara, realmente, o pagamento é uma feature de suporte bem legal é interessante ninguém consegue acessar a Netflix com pagamento mas assim, a gente tá num mundo de vídeos aqui você não acha que tem alguma outra feature que poderia brilhar mais que pagamento? entende? então prova, o entrevistador, a pessoa, ela vai sempre tentar te conduzir de uma forma ou de outra. Mas, novamente, não tem certo e errado. E muitas vezes, isso aqui pode vir pronto para você. Agora, aqui a gente entra em requisitos não funcionais tudo que termina com iridade availability, disponibilidade escalabilidade e etc normalmente isso acaba sendo requisito não funcional o que é um requisito não funcional? ele tende muito mais a trabalhar com o comportamento do sistema do que o recurso em si. Por exemplo, requisitos funcionais aqui, eu não estou sendo específico, tá, galera? Mas a disponibilidade desse sistema tem que ser muito alta para que eu tenha uma grande carga de pessoas acessando de tudo quanto é lado e etc. Escalabilidade, no sistema ele precisa poder escalar. Baixa latência, mesmo com internet lenta. Isso aqui, a gente sempre vai ouvir de forma geral. Mas quando a gente cai nesses aspectos, isso aqui muda muito também a forma como a gente vai trabalhar. Por exemplo, se eu falo que o meu requisito é alta disponibilidade, provavelmente é porque eu estou trabalhando com um sistema mais de missão crítica que não pode ficar fora do ar. Existem sistemas que, por incrível que pareça, que a disponibilidade não é a coisa mais importante do mundo. Imagina que você tem o sistema da sua empresa que tem 10 pessoas acessando e que se de madrugada ele ficar fora do ar não vai matar ninguém tá, então não que o sistema não tenha que estar disponível mas a minha preocupação com disponibilidade aqui não é tão grande mesma coisa com escalabilidade tem sistema que ele é tão o nível de utilização dele é tão baixa ou que existem coisas na frente disso que a parte de escalabilidade não é tão grande e isso modifica completamente a minha arquitetura, por exemplo escalabilidade, com certeza eu tenho que ter vários serviços, os sistemas tem que ser stateless, esses sistemas provavelmente precisam de load balancers, precisam de formas diferentes de provisionar então tem diversas formas de você trabalhar se eu não preciso nada disso e não tenho que ter foco em escalabilidade, eu vou simplesmente fazer o deploy da forma mais simples possível desse sistema. Eu vou controlando as minhas máquinas virtuais, por exemplo, de acordo com o recurso computacional. Agora, por exemplo, aqui. Upload de vídeos grandes. Aí a coisa já começa a mudar também o requisito não funcional, porque muda completamente a forma inclusive com que eu vou desenhar o sistema. Como que eu faço um upload realmente de arquivos bem grandes aí? Então, isso aí é um ponto importante. Muda como eu vou arquitetar o meu sistema. Baixa a latência mesmo com internet lenta. Acontece com todo mundo no final das contas. Você está no celular, você está em locais e você ainda assim quer assistir a Netflix. Como que eu consigo manter baixa latência, mas também ainda conseguir assistir vídeos mesmo que a minha internet tenha baixa qualidade naquele momento. Então, isso são requisitos que a gente tem que levar em conta na hora que a gente vai desenhar. Tá? E agora a gente entra nos pontos que principalmente quem nunca ouviu falar em System Design ou tá tendo contato pela primeira vez, a gente vai falar sobre plano de capacidade. A forma como a gente vai fazer o plano de capacidade a forma como a gente vai fazer o plano de capacidade aqui galera é papel de pão tá, é basicamente ele é papel de pão e eu estou trazendo colinhas aqui que a gente usa no próprio curso e que vocês tem acesso ou quando forem ter acesso ao módulo tá mas basicamente o plano de capacidade vai te ajudar a ter uma ideia da quantidade de recursos que você vai utilizar para conseguir rodar esses sistemas. O grande ponto é que, para fazer plano de capacidade, é muito complexo você conseguir fazer isso de cabeça. A pessoa fala assim, um vídeo tem 30 minutos, quantos vídeos eu consigo ter em um dia? Por segundo. Ferrou. Daí você já começa a pensar. Quantos segundos tem um dia? Acabou. A brincadeira já é aí. Você já não consegue fazer nenhuma conta. Basicamente isso. Então, normalmente, quando você for fazer planos de capacidade, principalmente em entrevistas, tá, galera? Pelo amor de Deus, não vão fazer plano de capacidade na empresa de vocês com números tão arredondados, porque pode dar ruim, tá? Planos de capacidade, quando você vai colocar no seu sistema, na sua empresa, você tem que trazer os dados mais assertivos possíveis. Mas, mesmo assim, aqui você consegue pelo menos ter uma ideia do que você vai precisar utilizar, tá? E aí, baseado nisso, uma das coisas que eu sempre vou falar pra vocês e aí nesse caso é de entrevista, tá? Que é o seguinte, sempre quando você for começar a fazer o System Design, a quantidade de perguntas que você fizer vai ser melhor. E muitas vezes você vai ter pegadinha que o próprio entrevistador, por exemplo, ele não vai te dar todos os dados que você precisa. E aí você tem duas opções, fazer isso supondo da sua cabeça ou perguntando. Então sempre pergunte ao máximo. Inclusive na empresa que você trabalha. Alguém pediu para você desenvolver o sistema, você fala, cara, baseado no histórico que a gente tem aqui no sistema da empresa, quantos usuários que a gente tem todo dia, por exemplo? Então, aqui no caso da Netflix, a gente colocou fonte cabeça do Wesley. 50 milhões de usuários ativos diariamente. Quantos vídeos são assistidos por dia por usuário? Coloquei um. Em horários de pico, o acesso cresce em 15 vezes. Cada vídeo possui em torno de 30 minutos. O tamanho do vídeo por minuto é de 30 megas, tá? Ou seja, a cada minuto de vídeo, eu tenho 30 megas aí no meu storage. E aqui, a proporção de leitura e escrita. Ou seja, pra cada 100 leituras que eu faço, eu vou ter uma gravação. E aqui, a gente tem algo que a gente chama de replication factor. Replication Factor. Replication Factor é algo de a quantidade de cópias desses dados que a gente vai ter para questões inclusive de disponibilidade. Então se eu tenho Replication Factor de 3, significa que eu vou ter esses dados replicados 3 vezes. Então eu vou multiplicar por 3 a quantidade de dados que eu vou ter esses dados replicados 3 vezes. Então, eu vou multiplicar por 3 a quantidade de dados que eu vou gravar. Então, esse replication factor, ele é super importante porque em nenhum lugar do mundo você vai ter apenas um dado. Esse dado, ele tem que estar replicado em algum local. Então, normalmente você trabalha com um fator de replicação e nesse caso é 3 vezes. E aí, galera, tá? Vamos a algumas formas de facilitar a nossa vida na hora que a gente for trabalhar com plano de capacidade, tá? Quem aqui gostava de notação científica na escola, no ensino médio, na faculdade? Só tem uma pessoa aqui e eu tenho que falar pra vocês que eu também nunca gostei mas eu comecei a gostar muito quando eu comecei a fazer planos de capacidade porque é muito mais fácil usar isso aqui do que necessariamente fazer as contas na mão e você que não lembra ou talvez esteja um pouco enferrujado aí na parte de notação científica, essa aqui é uma colinha bem simples pra pra tá sempre ali do seu lado, pra você conseguir fazer as contas de cabeça de uma forma um pouco mais rápida, tá? E a conta, basicamente, é sempre pensando em 10 elevado a algum número. Então, quanto que é 1.000? 10 elevado a 3. Quanto que é 10.000? 10 elevado a 4. 100.000? 10 elevado a 5. 1.000.000? 10 elevado a 6. E aí, às vezes, a gente precisa multiplicar informações. Então, para a gente multiplicar a notação científica, a gente simplesmente soma os valores que estão aqui elevados, então por exemplo para eu multiplicar 10 elevado a 5 vezes 10 elevado a 3 vai ser 10 elevado a 5 mais 3 que é 10 elevado a 8 a divisão é a mesma coisa, mas a gente vai subtrair e aí a gente tem também uma pequena tabelinha simples de conversão. Mega pra giga, giga pra tera, mega pra tera. Então se eu quiser converter algo de mega pra giga, eu multiplico por 10 elevado a 3. Se eu quiser de giga pra tera, eu faço 10 elevado a 3. De mega pra tera, 10 elevado a 6. Galera, quem aqui ficou assustado com o que viu, com o que eu falei já tá falando, cara, do que esse cara tá falando agora e o porquê que eu vou usar isso sejam honestos e levantem, deixa eu colocar o chat aqui que eu não tô conseguindo acompanhar, peraí deixa eu colocar o chat aqui do meu lado, porque eu consigo acompanhar vamos lá tem um monte de gente aqui, ó eu, trauma e etc, né show de bola então a gente vai fazer bem passo a passo isso aí e vocês vão perceber que a parada não é tão complexa assim, tá então, o que que acontece a funciona da seguinte forma primeira coisa que a gente vai pensar na hora de montar o plano de capacidade Então, o que acontece? Funciona da seguinte forma. Primeira coisa que a gente vai pensar na hora de montar o plano de capacidade é conseguir ver o throughput ou as requests, a quantidade de requests que o nosso sistema vai conseguir trazer. Ou seja, a gente vai sempre tentar partir de requests por segundo, RPS. sempre tentar partir de requests por segundo, RPS. Então, como que eu consigo saber quantas requests por segundo eu tenho? Basicamente, eu vou pegar minha quantidade de requests que eu tenho por dia e divido pela quantidade de segundos por dia. Porém, imagina você tentando fazer essa conta com aquela pressão nas suas costas e alguém te fala, 24 horas tem 86.400 segundos. Então, pegue 50 milhões e divida por 86.400. Cara, o que vai acontecer é que vai acabar a entrevista e você ainda vai estar fazendo essa divisão. A real que vai acontecer é isso. Então, o que você pode fazer nesse tipo de situação? arredondamento, então ao invés de eu partir do princípio que um dia tem 86.400 segundos eu vou partir do princípio que um dia tem 100.000 segundos é arredondamento galera, vai dar diferença? vai, mas a diferença não vai ser tão gigante ao ponto de te atrapalhar pra criar o system design. A gente não tá atrás de precisão aqui pra gente, tá, galera? Então, isso aí é um ponto, assim, super importante pra gente conseguir trabalhar. Então, o que que acontece? Se eu tô arredondando, tá, um dia pra 100 mil segundos, lembra o que é 100 mil? 10 elevado a quinta. Então o que eu tô querendo dizer é que um dia é igual a 10 elevado a quinta. É basicamente isso aqui que eu tô querendo dizer. Então como que a gente poderia calcular as requests por segundo do nosso system design aí da Netflix? Tá? Como que a gente poderia fazer aqui? Então, se eu tenho que as minhas requests por dia é diferente, é dividido pelos segundos dos dias e a gente tem aqui 100 mil segundos, como que eu poderia fazer aqui nesse meu caso? Os dados que a gente tem aqui, basicamente, a gente está falando que são 50 milhões, tá? De acessos que a gente tem então o que que eu posso simplesmente colocar aqui nesse meu caso eu posso pegar os meus 50 milhões certo? eu posso pegar aqui os meus 50 milhões e dividir pela minha quantidade de dias, de segundos que eu tenho por dia, né? milhões e dividir pela minha quantidade de dias, de segundos que eu tenho por dia, né? Segundos por dia. Mas eu não vou fazer a conta com 86.400 segundos. Eu vou fazer essa conta com o quê? No final do dia? Eu vou fazer essa conta com 10 elevado a 3, que eu tenho no final das contas 100 mil segundos aqui pra mim. Ok? Oi? Ah, a quinta, perdão, galera. Perdão, perdão, perdão. Galera, e por favor, tá? Sempre quando eu errar, me corrijam, tá? Por favor, podem ficar na liberdade de botar o microfone aí, tá? e aqui a mesma coisa, se eu tô falando de 50 milhões, 1 milhão é 10 elevado a 6 certo? então o que que eu posso colocar aqui? eu posso colocar que eu tenho 50 vezes 10 elevado a 6 maravilha? tá fazendo sentido pra vocês, galera? 50 vezes 10 elevado a 6. Maravilha? Está fazendo sentido para vocês, galera? Ou pode ser 5 vezes 10 elevado a 7. Então, basicamente, acaba dando aqui na mesma. E quando eu sei esse resultado aqui no final do dia, eu vou chegar na pegada que vai ser o seguinte. Ou é 50 10 elevado a 6 ou 5 elevado a 7. Vamos colocar assim que fica mais fácil. E no final do dia, isso vai significar o quê? Que eu tenho 5 vezes 10 elevado a 2. Porque se eu estou dividindo, eu vou subtrair o 7 do 5, eu vou ter 2. E aí 5 elevado a 2, 5 vezes 10 elevado a 2 é 500 agora mesmo esquema tá a em relação a o write e reads a gente acaba chegando nesses mesmos tipos de situação mas eu tenho que lembrar aqui, que aqui é acesso geral, né? Vou colocar aqui acesso regular. Por quê? Porque eu tenho os horários de pico aqui para mim, tá? Então, o que vai acontecer? Eu vou colocar RPS em horários de pico. E aí, eu sei que ele tem uma diferença, porque ele é 15 vezes maior em horário de pico ali para mim. Então o que eu posso fazer? Eu posso pegar 500 multiplicado por 15, e aí no meu caso vai dar 7.500. E para quem gosta, ainda quer manter a notação científica, vai dar 7.5 vezes 10 elevado a a 4? A 3. A 3. A 3 é depois da vírgula. É isso aí, Sérgio. Perfeito. Tá corrigido. Só tô vendo se vocês estão espertos, tá, galera? Só pra ver se vocês estão ficando espertos aí. Em relação à leitura e à escrita, tá, pessoal? Existem algumas formas de fazer, e vai depender do seu nível de preciosismo, e vai depender do seu nível de arredondamento, tá? Porque, se eu falo que eu tenho 100 escritas pra uma leitura, significa o quê? Opa, se eu tenho 100 leituras para uma escrita, significa que eu tive 100 requests mais uma. Ou seja, eu estou falando de 101 requests. Se eu for fazer essa conta quebrada dessa forma, eu também estou enrolado. Ou eu posso falar, cada 99 leituras, uma escrita. Ainda assim, eu estou enrolado. Então, quando alguém colocar para você 100 para 1, faz a conta de leituras com 100 e faz a quantidade de escritas com 1 e acabou. A não ser que queiram começar a explorar, mas normalmente nesse tipo de conta, ninguém está tão preocupado nesse momento, nesses níveis de detalhe. O importante aqui é que a gente pelo menos tenha uma ideia de como é que esse sistema está. O mais importante é a pessoa entender como que está a sua linha de raciocínio e não o seu nível de exatidão ali. No nosso caso, em relação à leitura, nível de exatidão ali no nosso caso, em relação a leitura, a gente tem 100 leituras para 500 caras aqui basicamente eu vou ter 50 mil é isso? e a gravação basicamente vai ser a mesma coisa, mas vai ser 5, basicamente é isso? é 1 vezes 500, é 5 vezes 10 elevado a 2 mas vai ser 5, né? Basicamente. É isso? 1 vezes 500 é 5 vezes 10 elevado a 2. Vai ser 500 ali pra mim. Wesley, 50 mil leituras por segundo nesse caso? Na realidade, é a proporção que eu vou conseguir trabalhar, tá? É basicamente a proporção que eu tô trabalhando. Agora, um ponto que é importante aqui pra vocês se ligarem é, tá? Toda vez que vocês, opa, quer dizer, 100 reads pra cada RPS, na realidade, eu entendi o que você tá dizendo, na realidade não é 50 mil, né? É nessa proporção aqui dos 500, quantos desses 500 acabam entrando aqui para a leitura, fez sentido para vocês galera? fez sentido? eu tinha entendido que write ia ser 5 e reads 495, alguma coisa assim. Mais ou menos isso, porque você tá acabando, basicamente é o nível de proporção, porque a gente tá fazendo com 5, acaba sendo isso mesmo. A cada, então, 5 leituras, as 5 gravações, eu vou ter 495 escritas, é isso, né? Daí tem que bater o número do meu número de RPS aqui. Sem ser chato, não seria 4 e 496? Porque a cada 100 é 1. Então, foi exatamente isso que eu falei pra vocês agora no começo. Você pode partir do princípio que são 101 e daí eu dou 5,495 ou eu posso ser chato, tô brincando, mas é simplesmente a forma,495. Ou eu posso ser chato. Estou brincando. Mas é simplesmente a forma de interpretar. Ou eu posso colocar a cada realmente... É porque assim, a cada 100 leituras eu tenho uma escrita. Aí eu estou falando de 101. Agora eu posso colocar em cada 100 operações, 99 são de leitura e uma de escrita. Então, é... Tá? Mas assim, eu vou ser honesto com vocês. Depende muito de como... A não ser que o entrevistador chegue nesse nível. Eu acho muito difícil. Isso aqui, galera, é a forma mais fácil de eu resolver. Porque começou a cair número quebrado, acabou a sua mente na hora que você vai ter que fazer qualquer tipo de cálculo. Entendi, mas só por uma visão de entender se a postura seria válida, tá? Entendendo que é uma questão de interpretação de texto, seria prudente, caso você identifique que o cara tá estranhando a sua resposta, justifica. Eu li aqui, entendi que era 101, mas 4, 4,96. O que eu recomendo, inclusive, vai até um pouco além disso, tá? Vocês estão percebendo como é que eu tô explicando aqui pra vocês? Perceba que eu estou resolvendo e estou explicando. Quando você estiver numa entrevista, o que você vai fazer é exatamente o mesmo. Porque a pessoa, o importante de tudo isso, é a pessoa entender a linha de raciocínio. Porque se eu chegar aqui, ó, deu 7.5 elevado, mais 10 elevado a 3, o cara falou assim, velho, da onde você apareceu com esse número? Você é o Einstein. Entendeu? Então é importante colocar. Então na hora que a gente está fazendo esse ponto aqui, foi mais ou menos que eu acabei falando. Olha, tem duas formas de eu interpretar. Eu estou partindo do princípio dessa forma. Então, é sempre importante ir falando a sua linha de raciocínio. Show? Se tivesse colocado 102.1, aí poderia ser essa questão de 10%, né? Sim, mas, novamente, quanto mais você falar e explicitar, vale a pena. Mesmo que alguém chegue e fale, olha, é de 100 para 1, né? Que normalmente eu coloco assim, a cada 100 leituras eu tenho uma escrita. Então, é sempre importante você conseguir confirmar essa informação. Porque vai da cabeça da pessoa, óbvio que existem padrões, é a mesma coisa você falar, sei lá, de P99, P95, mas se você olhar, às vezes algumas pessoas interpretam de jeito. Então, quando chegar aqui, você pode chegar e falar assim, bom, você tá colocando de 100 pra 1, é, você tá dizendo então que a cada 100 gravações eu tenho uma escrita. Então, a gente está falando no total de 101 operações normalmente quando colocam assim está querendo dizer isso, tá? 101, agora se você fala assim, olha, eu tenho 100 escritas e quer dizer, uma escrita a cada 100 leituras a gente está falando de 101 tá? é basicamente isso que você colocou, é o 100 para 1 mas normalmente esse 100 para 1 é quantidade de operações então é importante lembrar no total de operações, a cada 100 operações de leitura, eu tenho uma descrita mas assim, a melhor forma de você resolver esses tipos de problema é o que? é falando e facilitando tentando deixar mais claro resolver esses tipos de problema é o que? É falando e facilitando, tentando deixar mais claro o que você tá fazendo. E eu sempre vou prezar por tentar deixar os números os mais como se diz simples possíveis de eu conseguir fazer conta. Evitar quebrado pra tudo quanto é lado, porque começou a quebrar a minha cabeça, ela já começa a enrolar. Tá? Agora, a gente tem uma começou a quebrar a minha cabeça, ela já começa a enrolar, tá? Agora, a gente tem uma outra coisa que é a banda que a gente vai utilizar, né? E a parte de banda, ela é uma parte também importante, porque vai depender muito de quanto que, por exemplo, eu vou gastar com o servidor e tudo mais, né? Então, a gente tem nesse caso aqui, uma regra, né? O tamanho do vídeo é de quanto? é de médio a cada 30 minutos do tamanho de vídeo 30 minutos ele gera 30 megas pra mim, ou seja a média minha por vídeo é de 900 megas fez sentido né? sim tá, e Ou seja, a média minha por vídeo é de 900 megas. Fez sentido, né? Sim. Tá? E eu coloquei de propósito aqui no System Design, tá? Um valor baixo, mas normalmente esse valor é bem maior aqui, tanto o tempo de vídeo, não só o tempo de vídeo, mas a quantidade, porque depois a gente vai falar que existem nos processos de transcoding e de pipelines de vídeo, esses tempos vão aumentando muito por conta das resoluções e tudo mais. Mas, novamente, a gente está pegando os dados que a gente tem e colocando aqui. Legal? Então, partindo desse princípio, o que acontece? Nesse caso, se eu tenho as minhas 500 requisições por segundo, nesse meu caso, o que isso vai acontecer? Eu vou precisar ter uma conta muito louca para eu fazer cálculo de quantos megas por segundo eu tô gastando. No final das contas é isso, né? Esse que é o grande ponto. Então, como que a gente conseguiria tentar fazer esses tipos de conta pra facilitar um pouco a nossa vida? Não tem jeito. Aí a gente não vai poder muito escapar da calculadora. Eu vou ter que fazer algum cálculo do tipo 900 megas vezes 1024, para eu saber os dados em kbytes, né? E eu posso, por exemplo, também dividir pela quantidade de megas. Então, isso aí é um dos pontos, assim, bem importantes que você sempre vai ter que tentar lidar no meio dessas histórias então já teve gente aqui que colocou, dá 500kb por segundo né 900mb, será que é 500kb? eu posso pegar fazer uma conta rápida, vocês conseguem ver a minha calculadora aqui? não acho que eu não estou compartilhando a tela inteira vocês conseguem ver a minha calculadora aqui? Não. Ah, eu acho que eu não estou compartilhando a tela inteira. Não. Não, não vão ver mesmo, porque eu estou compartilhando só a janela. Mas, basicamente, em kbytes, isso vai dar 921.600 kbytes por segundo. Mas eu quero pegar os dados em mega. O que eu posso fazer? Dividir esse cara ali por 1.024. No final das contas, isso vai dar 450.000 MB por segundo. por segundo, que no final das contas vai dar 4.5 vezes 10 elevado a 5. Alguém acompanhou meu raciocínio aí? Ué, eu já me perdi ali quando você trocou as unidades. Estava vezes segundo, virou dividido por segundo, eu já me enrolei ali. Tá, vamos lá aqui que a gente tá trabalhando, na realidade só foi uma conversão de kbytes pra megabytes no final das contas porque eu tive que multiplicar aqui por 1024 não, então vamos lá, a gente tá multiplicando ali dado vezes tempo a gente cai na segunda continua dado vezes tempo, de repente cai na segunda, continua dado vezes tempo. De repente a gente virou taxa, dado por tempo. Onde que essa conversão aconteceu? É, mas exatamente é dado por tempo. Porque a bandwidth é exatamente isso. Quanto que eu estou consumindo de bytes por segundo. Entendeu? Então eu tenho o tamanho do meu pacote. Wesley, se em um minuto é 30 MB, para converter de 30 para segundo não é mais fácil do que de meia hora? Por isso que eu botei os 500 MB ali. Mas, cara, dá uma diferença meio que grande, né, cara? De 500 para 450, hein? Esse que é o grande ponto. Você dividiu por 1.024 ou multiplicou por 1.024? Esse 92600. É 1.024. Você dividiu ou multiplicou? Você pega o valor. Kbyte é 964. Então, se você pegar 500 vezes o valor em Kbyte e dividir por 1024, você vai ter o resultado em mega da mesma forma, entendeu? Entendi. Então, caras, de forma geral, existem várias formas de você arredondar. O importante, tá? O que eu ponto ali... Ah, tem gente que falou, ó, é importante ter o minuto como base, mas calma aí, tá? Vamos pensar o seguinte, eu posso fazer a partir dos meus segundos, a conversão que eu quiser agora, tá? Eu vou dar um exemplo aqui pra vocês, tá? Pra gente não ter que ficar fazendo aqui a bandwidth em todas as unidades, vamos fazer a mesma coisa com o storage. Olha só. Como é que é o storage? É a quantidade de writes que eu tenho, certo? Vezes o tamanho da minha requisição, vezes o meu replication factor. Ok? O meu replication factor é de quanto? É de 3. Então, por exemplo, se eu pego 500 writes que eu vou ter, na realidade não é 500, nesse caso acaba sendo 5, né? 5 writes vezes 900 vezes 3, isso dá quanto, galera? Dá 1.350, deixa eu botar na calculadora só para não passar muita vergonha, Deixa eu botar na calculadora só para não passar muita vergonha. 5 vezes 900, vezes 3. Os universitários... 3,500. 3,500 mesmo, né? Estou certo, né? Beleza. Então, eu tenho aqui os meus 3,500. Então, esses meus 3,500 aqui, no final das contas, é a quantidade de storage que eu estou gastando por segundo correto? então nesse momento eu estou trabalhando aqui com segundo, porque eu estou trabalhando com segundo? porque essas 5 requests aqui são as minhas requests que eu estou trabalhando com segundo? Porque essas cinco requests aqui são as minhas requests que eu estou trabalhando por segundo. Então, por isso que a gente acaba trabalhando aqui com a unidade de segundo aqui nesse caso. Então, isso aí é um ponto aqui importante para a gente acabar lembrando. Mas, agora que a gente tem esse dado aqui por segundo, isso aqui acaba representando 1.35 vezes 10 elevado a 3, é isso? Esse é 4. Esse é 4. É 13 mil, né? Passou de 10 mil, é 4. Beleza. Então, eu tenho essa minha conta agora aqui. Agora, se eu quiser fazer isso aqui, vou colocar até aqui separado para a gente. Segundo, e aí, normalmente o que eu vou recomendar, sempre coloque, você pode colocar por dia, você pode colocar por ano, e você pode colocar por cinco anos. Aí vai depender do preciosismo e dependendo de como você queira trabalhar em relação ao seu tempo aí nesse caso. Mas de forma geral, aí por dia, eu acho que está bem claro o que a gente acaba tendo que fazer, né? É acabar multiplicando pela quantidade de tempo que a gente acaba tendo ali por dia. Certo? Agora, um dia tem 100 mil segundos. certo? agora um dia tem 100 mil segundos então no final das contas eu teria 1.35 vezes 10 elevado a 4 é isso mesmo 10 elevado a 4 vezes 10 elevado a 5, é isso? É isso. É isso. Isso aqui é o resultado do meu dia aqui pra mim. E aí eu vou ter esse resultado em megas no final das contas, né? E aí não é muito legal eu ter isso em megas, porque eu vou ter aqui 1.35, que chato pra caramba, eu ter isso em megas, porque eu vou ter aqui 1.35, que chato pra caramba, vezes 10 elevado a 9, é isso? E aqui tá em megas. Caras, quando começa a ficar storage desse jeito, é melhor fazer o que? Transferir megas, nesse caso, pelo menos pra tera, né? Então, pra eu transferir esse cara para teras, isso daria que 1 terem 24 por 2. Aqui a gente tem a conversão. Se vocês olharem, mega para tera. 10 elevado a 6. Então, acaba dividindo esse cara. Então, fica 1.35 vezes 10 elevado a 3 terabytes. Fez sentido? 9 menos 6 é 3? É isso aí, né? Como a gente foi dos megas, pode subir só um pouquinho ali? Opa! Aqui no... Não, na outra ali, que a gente estava saindo da conversa. Essa daí. A gente tem 30 minutos vezes 30 megas, 900. Eu entendi que isso 921 cabais, aí são 900 megas, mas esses 450 megas por segundo, como que a gente muda esse valor? Eu me perdi um pouco aí. Basicamente, eu fiz a divisão desse cara pelo 1024. Ah, tá, tá, entendi, entendi. Mas por que a gente já considerou o segundo nesse caso, sendo que ali tava em megas, os 900 megas não tem essa proporção? Porque, na realidade, a gente tá sempre multiplicando isso por 100, porque a gente tem a quantidade de operações que a gente está colocando, entendeu? Quer dizer, por 100 não. O que você dividiu o quê para o 1.024? Essa é a parte que eu estou perdido também, cara. Galera, vamos fazer o seguinte. Não está batendo o valor. Vamos fazer o seguinte. Deixa eu só passar por essas partes aqui. A gente vai para o System Design e a gente pode separar uma parte aqui, só para a gente falar dos números, pode ser? Beleza. Fechou? Perfeito. Ano e cinco anos. Eu não vou nem gastar o nosso tempo aqui. O ano é multiplicar por 365 dias, pegar o resultado do ano e multiplicar por cinco. Então, aí basicamente é isso. Então, é o dia multiplicado por... É pegar o dia multiplicado por 365. E aqui é pegar o dia multiplicado por 365 vezes 5. Basicamente é isso aqui. Agora, um ponto que sempre vai cair, galera, e isso aí é um ponto importante para a gente conseguir trabalhar, que é o seguinte. Olha só que interessante, pessoal. Toda hora que a gente for falar de System Design, você vai ter que, de uma forma ou de outra, pensar em como que os dados são modelados. Mas, é aqui que a gente tem que tomar cuidado, tá? E aqui é uma pegadinha, então, fiquem ligados com isso. Como que você consegue modelar dados no System Design? Porque, nesse momento ainda, a gente não tem tanta clareza de qual banco de dados vai utilizar, para qual tecnologia. A ideia é que você tenha um mapa mental na sua cabeça de como que essa informação vai ajudar você a organizar os pontos principais do seu dia a dia. Como assim? Vou dar um exemplo aqui para vocês. Toda vez que você vai modelar algo, isso faz automaticamente você pensar nas entidades que você está trabalhando. Faz sentido o que eu estou dizendo? Sim. Sim. Certo? Quais entidades que eu tenho aqui, galera? Vídeo. Vídeo, né? Então vamos lá. Eu tenho meu vídeo aqui. Então vamos lá. Colocar aqui, vídeo. Vídeo, espectador. Vamos lá Vamos pensar sempre no domínio O que o cara vai precisar ver O cara tem um vídeo Aí alguém falou espectador, né? Cara, esse cara trabalha na televisão Eu vou chamar de... Eu vou chamar de usuário Pode ser? Não fica bravo comigo Eu vou chamar de user Vai ter os criadores eu vou deixar o usuário de forma comum agora, o ponto é o seguinte eu acho que aqui é o ponto mais importante que é o que vai mudar o jogo na hora que a gente vai pensar na estrutura de como esse sistema vai funcionar por que? o que o vídeo que a gente vai pensar na estrutura de como esse sistema vai funcionar. Por quê? O que o vídeo ele representa pra gente? A gente tem o vídeo que são os arquivos físicos que a gente vai ter realmente armazenado e a gente tem o vídeo com os dados que a gente precisa do vídeo. Faz sentido o que eu tô dizendo? Faz, né? Sim. Com certeza os vídeos os vídeos têm muitos dados que vão, na realidade, trazer mais informações de onde esse cara vem. Então, o que normalmente a gente espera fazer? Tentar deixar muito claro que dentro dos vídeos eu tenho metadados que vão conseguir me ajudar a fazer as relações dos vídeos que eu tenho por exemplo tá eu posso ter aqui no meu vídeo vamos colocar aqui dentro do meu vídeo eu posso ter sem problema algum o meu vídeo aí dia aqui tá super feliz aqui com meu vídeo aí dia que eu preciso ter mesmo. Deixa eu aumentar essa fonte aqui para ficar melhor. Deixa eu colocar um verdinho. Nossa, cara, o verdinho ficou muito ruim. Eu tenho o meu Video ID, onde eu vou ter dados. Mas esse vídeo vai ter bastante coisa referente a ele, que são metadados que vão me ajudar a localizar o vídeo, a URL, mais dados de descrição, ou seja, são diversas descrições além das informações dos vídeos. O que você pode sempre fazer é o seguinte, que um vídeo pode ter um conjunto de metadados. Por quê? Vamos imaginar que o vídeo é separado por segmentos. Faz sentido, né? Alguém já trabalhou com vídeo em algum momento? Não. Normalmente, vídeos são separados em pequenos pedaços. Chunks. São os chunks dos vídeos, exatamente isso. E esses chunks podem estar armazenados Em lugares diferentes Às vezes eles tem URLs diferentes Então tem bastante informação que a gente pode colocar O que a gente pode fazer É, além dos dados do vídeo E eu não quero ficar descrevendo todos os dados Eu posso colocar Um conjunto de metadados E falar que esse conjunto de metadados eles vão ser dados importantes para eu conseguir trabalhar com vídeo. Então eu posso colocar uma tabela de metadados aqui e aqui nessa tabela eu posso ter deixa eu copiar aqui o metadados seria uma lista? Exatamente, eu tenho uma lista de vários metadados desse vídeo porque imagina que eu tenho uma lista de vários metadados desse vídeo, porque imagina que eu tenho, por exemplo, vários chunks desses vídeos, ou seja, vários pedaços desses vídeos apontando para URLs diferentes. Certo? Então, eu tenho vários metadados dentro do meu próprio vídeo. Entendeu? Eu posso ter diversas coisas, diversas informações. Mas, de forma geral, o vídeo, de? Eu posso ter diversas coisas, diversas informações, mas de forma geral o vídeo, de uma forma geral ele vai ter o ID do vídeo, ele vai ter a descrição do vídeo, ele vai ter o URL do vídeo, ele vai ter o tempo que o vídeo colocou, mas é importante a gente sempre destacar aqui que eu posso ter diversas outras informações que vão compor esse vídeo, tá? Por exemplo, os chunks que esses vídeos podem ter, os pedaços que eles vão ter. Então, esse é um tipo de informação que pode ser perguntado ou que possa acabar colocando aqui. Mas, obviamente, eu posso colocar o vídeo ID, o nome do vídeo, nome, a descrição do vídeo. Eu posso colocar diversas outras informações que têm a ver com o meu vídeo em si. Agora, definir que a gente tem uma tabela de metadados sempre vai ajudar. E olha só, galera, não é só para vídeo, tá? Por que eu estou dizendo isso? Vamos ao seguinte. Imagina que você tá num modelo que é meio obscuro pra você por exemplo, vídeos eu acredito que a maioria das pessoas aqui tá? no final das contas essas pessoas não são especialistas em vídeos então você sabe tudo? todas as informações que contém num vídeo? Acho que não contém. Não contém, certo? A maioria das pessoas que não entendem daquele domínio é a mesma coisa se alguém perguntar de banco pra mim. Eu não sei todas as informações dos bancos. O que que eu faço? Eu falo o seguinte, cara, isso aqui são metadados. São dados que vão me ajudar a eu resolver esse meu tipo de problema. Então eu aponto aqui, ó, todos os outros dados correlatos pra esse cara, eu vou trabalhar aqui com metadata. Metadata, né? Metadados. Basicamente isso. E um dos pontos aqui pra mim que eu sei que são importantes são os chunks. Isso eu tenho certeza, que são os meus pedaços de vídeos que eu vou acabar de trabalhar. Então, acho que isso aí é um ponto importante pra trabalhar. O usuário, ele é uma entidade importante, né? É o espectador nosso, né? A gente tem um cara importante. Agora, olha só que interessante, pessoal. Toda vez que você vai modelar qualquer coisa no seu System Design, você tem que manter sempre um escopo. Qual é esse escopo? O escopo vai ser o seguinte. Você vai voltar aqui nos seus requisitos e vai falar, o que eu pedi pra fazer? Playback. Eu tenho vídeo? Tenho. Alguém vai assistir o vídeo? Tenho. Alguém vai fazer o upload do vídeo? Tenho Alguém vai fazer o upload do vídeo? Tem, o usuário. Ok? Support features. Search. Opa! Olha só que interessante. Tem algum lugar mais legal pra eu colocar metadados pra fazer a busca do que o meu search? Então, aqui já começa a me ajudar aquela parte de metadados. Mas eu também falei aqui que eu ia colocar DRM. Então, eu resolvi entrar nessa seara aqui que eu vou falar, eu vou ter que tratar de DRM. Então, não vai ter jeito. Se eu falei que eu vou tratar de DRM aqui, eu vou ter que colocar aqui para mim, como entidades que eu vou trabalhar também a parte da DRM. Deixa eu só terminar o usuário aqui com a gente. Então, no caso do meu user, eu tenho o ID do meu usuário, eu tenho o nome do meu usuário, e eu tenho, por exemplo, a row do usuário. E daí, na row, eu já mato duas numa só. Eu tenho o cliente e eu tenho o administrador. Ponto. Os metadados vão me ajudar com o search, por exemplo. E eu vou precisar de quem também? Da DRM. Só para vocês saberem, pessoal, para dar um contexto em quem nunca ouviu falar em DRM, basicamente a DRM funciona da seguinte forma. Toda vez que você vai assistir um vídeo que você manda dar play, no processo que o manda dar play, no processo que o vídeo foi gerado, ele tem como se fosse uma URL de uma licença. Então quando você chama o vídeo, vai ser feito, o seu browser vai chamar um servidor externo, esse servidor externo vai verificar se o seu usuário tem permissão de ver aquele vídeo. Se o seu usuário tiver permissão de ver aquele vídeo, o que vai acontecer? Você vai receber uma requisição de volta falando, está aqui uma licença gerada para você poder ver esse vídeo dessa vez. E aí uma licença, ela é registrada e você vai poder fazer o play do vídeo. É basicamente isso. Então cada vez que você clica num play, é gerada uma licença da DRM pra você. E com essa licença, o seu browser, ele consegue dar o play. Depois a gente pode se aprofundar mais sobre DRM. Mas, como a gente falou, uma das coisas que aparentemente é importante na DRM é a licença, né? License ID. Eu preciso quem pediu, né? O user ID. O vídeo ID. E, por exemplo, eu posso ter um timestamp. Aqui para mim. Beleza? Quando eu estou colocando isso no final das contas, o que eu estou mostrando é, ah, eu entendo que DRM tem uma licença, que ela foi feita para aquele usuário, para aquele vídeo naquela data. Eu não preciso, pessoal, e isso é importante vocês ficarem se ligando, não precisa ficar, ah, o vídeo é um inteiro, o nome é uma string, é um varchar. Galera, esquece esse nível de detalhamento tá, o mais importante aqui nesse caso, é realmente você conseguir deixar claro como que você está estruturando a ideia do sistema na sua cabeça, eu tenho vídeo, eu tenho usuário, eu tenho as licenças que estão geradas, eu tenho os metadados que eu vou ter mais informações sobre os vídeos que vão me ajudar no search, que vão me ajudar a localizar os arquivos internamente. Eu não preciso ficar adicionando outros caras. Como que eu sei que eu não vou adicionar outros caras? Quando eu perceber que as entidades que eu falei, já fazem parte das minhas core features e das minhas support features. E por isso que essa definição inicial, ela é uma das mais importantes aqui para a gente. Por quê? Porque no final das contas, se eu colocar aqui recomendação, ponto. Aqui embaixo já vai mais uma cara aqui de recomendações de vídeo. E a coisa só vai crescendo. Então vamos sempre tentando deixar a parte estrutural mais simples possível, mas que, obviamente, você consiga explorar bastante coisa. Agora, a outra sacada aqui é API Design. No API Design, basicamente, o que você vai colocar é quais são as principais operações que esse meu sistema vai fazer. Tá? Então, alguém consegue falar uma das operações que eu preciso fazer aqui no meu sistema? O upload. Perfeito. Maravilha. Então, vamos aí devagar, então. Upload. Esse é um cara que, sem dúvidas, eu tenho que fazer. Então, vou colocar aqui upload. Como que eu descrevo uma API de upload? Um método. Recebe um post. Post. Post. Barra vídeos. Posso colocar os dados que eu vou receber. Que é o name Aí já entraria aquele metadados Que tu comentou ou não? Aqui ó Já tem os dados a mais que eu não sei quais todos são E eu tenho o arquivo Em si do vídeo Tá E se eu quiser ser ainda um pouco mais preciosista Aqui eu posso até colocar por exemplo, que ele vai retornar um 201 ok? mas o ponto importante que eu não quero que vocês se apeguem aqui é o nome é uma string o file é um blob e não sei o que, galera o Wesley em algum que eu participei, ele já pediu os códigos de erro também, entendeu? Para modelar. Perfeito. Aí é muito questão de comunicação, tá? E isso também vai depender muito para qual tipo de cargo que você está se aplicando. Eu vou dar um exemplo. Se você está aplicando para um cargo muito alto, na real, poucas pessoas vão estar até mesmo preocupados se é um 201. Se você está aplicando para um cargo, não estou dizendo, pelo amor de Deus, que você estava aplicando para um cargo baixo, mas o que normalmente acontece é, quem tem que saber código de cabeça, que você quer realmente garantir que sabe códigos de cabeça no final das contas? Ah, você vai pegar uma pessoa mais júnior, uma pessoa mais plena, você quer entender se o cara manja de rest no final das contas, os códigos de erro, o quanto isso é importante, entendeu? Então, nesse ponto, você pode colocar o código de erro só pra dizer, olha, tô colocando um 201. Dependendo do nível de posição que você vai colocar, a pessoa vai até ignorar isso. Porque aí fala assim, cara, eu tô criando um endpoint, cara, e o código de erro, eu já parto do princípio que você já sabe. Entendeu? Então, vai esse tipo de coisa. E tem gente que no chat escreveu, já vi principal engineer errando o HTTP code. E é o que mais acontece, galera. E, na real, eu não vou falar que ele tem que errar, mas o grande ponto é que, dependendo do nível que você está numa empresa, ou do trabalho que você tem que fazer decorar, entre aspas, os tipos de erro, tá? Ou os tipos de resposta do HTTP. Cara, assim, é o de menos naquela situação pra você. Entende? Então, depende muito, mas muito mesmo da posição que você tá colocado. Agora, você tá sendo contratado como staff engineer para projetar o design de APIs da empresa. Pô, aí eu posso cobrar isso de você de forma geral. Mas, normalmente, há sempre uma espécie de um bom senso do que vai ser perguntado em qual contexto. Então, sempre fiquem ligados. É óbvio, tá? É importante todo mundo saber os códigos de erro, HTTP, etc. Mas se você sair perguntando para mim, por exemplo, todos os códigos e não sei o quê, cara, eu não vou lembrar. Eu sei os principais de cabeça e acabou. Entendeu? Eu sei o quê? Erro 500, 404, 200, 201, que são os principais. Mas tem gente que fala, cara, esse erro é um erro 412. Tem gente que decora essas paradas, entendeu? Então, o importante, né, e obviamente, é você conseguir dizer a sua intenção. E a principal intenção aqui, no meu caso, é o post para dizer que eu vou criar um vídeo, criar um novo recurso ali para a gente, beleza? Então, isso aí é um ponto bem, assim, importante. Beleza? Então isso aí é um ponto bem assim importante. Fora o upload, o que mais que a gente tem que é importante a gente definir no nosso API design aqui, galera? Streaming. Content streaming. Tá, eu acho que quando você diz content streaming, você diz o playback do vídeo, né? O vídeo conseguir tocar, né? Isso, baixar ele e trazer no stream. Recuperar o vídeo, né? Normal vídeo conseguir tocar, né? Isso, baixar ele e trazer no chat. Recuperar o vídeo, né? Normalmente é chamado de playback. Ele tem que ter uma API que vai entregar o M3U, que é que vai fazer o... Eu acho que ele se referiu ao header, né? Eu acho que ele se referiu ao header. Aqui eu tô pensando, galera, sempre na operação, tá? Então, lembra que nos nossos requisitos eu tenho que fazer o playback do vídeo, ponto. Isso aqui é um endpoint. Basicamente, o que você sempre vai fazer é, o design da API que você vai modelar, vai ser sempre refletir nas core features, nas support features. Então, nesse caso aqui, provavelmente, eu vou ter um get, e esse meuvelmente eu vou ter um get, e esse meu get eu vou ter barra vídeos, barra playback, por exemplo, barra o ID do vídeo que eu vou querer tocar. E daí, baseado nisso, o que eu vou ter no final das contas? Eu vou pegar os dados do vídeo que eu vou receber e vou pegar as informações que eu preciso. Então, no final das contas, isso aqui vai, para mim, me retornar um código 200 com as informações que eu vou precisar do vídeo. Acabou. Eu não estou muito preocupado com todo o esquema ou coisas desse tipo. Oi. um todo esquema, coisas desse tipo. Oi? O DRM ficaria dentro do payback ou ficaria em uma parte separada? Sempre separado. Se eu coloquei aqui as features separadas, sempre tente trazer os endpoints correspondendo sempre com as features que você está colocando. Porque daí você consegue ser mais intencional na hora de apresentar. Por exemplo, eu coloquei o search, não coloquei? Sim. Então, ó. Opa, então eu vou botar um search aqui para mim também, porque eu estou mapeando basicamente aquilo que eu prometi que eu ia entregar. E aí nos vídeos, o que eu posso colocar? Eu posso colocar vídeos, search. E aí eu posso colocar, por exemplo, a query Que eu vou querer trabalhar E se eu quiser dizer Que eu vou trabalhar com paginação Eu coloco um page Igual a X Agora, galera, tomem cuidado Com todo o carinho do mundo, galera Com paginação Parece um negócio inocente, tá? Mas carinho do mundo, galera. Com paginação. Parece um negócio inocente, tá? Mas, quando a gente fala de search e paginação, lá na frente do System Design, o cara vai colocar assim pra você. Olha, eu vi que você colocou o search, vi que você colocou o page. Como é que funciona a paginação do Elasticsearch já que você vai usar o Elasticsearch para fazer a busca toda vez que eu fizer uma busca para uma determinada página sempre vai trazer os mesmos registros o que acontece se entrou novo registro durante esse tempo como é que eu faço como que eu consigo garantir os registros, o que acontece se entrou novo registro durante esse tempo? Como é que eu faço? Como que eu consigo garantir que eu não vou trazer páginas de registros repetidos conforme eu navegue nas páginas? Conseguem perceber que acaba caindo em uma situação muito complicada aqui para a gente? Mas contudo, no System Designer não vai dizer qual é a tecnologia, não? Opa, vai dizer sim. Com certeza, em algum momento você vai ter que falar qual tipo de informação que você vai trabalhar. E é vídeos barra... Decidi colocar o ID, né? Acho que assim rola bem. Vídeo, ID, search, a query que eu quero trabalhar e o page. Então, a gente tem que sempre ficar ligado com essas coisas. Coloquei uma gracinha. Tudo que eu coloquei pode ser... Gente, tem alguém com o microfone ligado. Podia fechar porque tá aparecendo aí. Tudo que eu coloco pode ser cobrado em relação a mim. Falei que vai ter um page, beleza. É a search, como é que funciona a paginação para eu fazer um Elasticsearch. Por exemplo, no Elasticsearch, eu posso criar um ponto no tempo e toda vez que eu fizer uma busca, naquele momento, passando aquele marco que eu acabei de colocar, eu garanto que os resultados da busca sempre vão ser o mesmo e ele mesmo que entrar novos registros indexados, eu vou poder manter essa consistência porque eu estou fazendo a busca baseado naquele ponto no tempo. Se eu não fizer e não marcar o ponto no tempo, quando eu mudar de paginação, por exemplo, o que vai acontecer? Pode ser que eu receba os mesmos registros nas páginas posteriores ou anteriores porque o banco de dados foi reindexado naquele momento. Então, é sempre importante estar ligado. Não estou dizendo que não é para colocar essas opções, pessoal, mas sempre você ter aquela mentalidade do tipo, coloquei algo, vou ter que explicar. E daí vai depender do nível de profundidade. Eventualmente, se você colocar a paginação aqui, o pessoal vai falar, legal, vai ter paginação. Como é que você pode retornar? Ah, eu posso retornar um 200, e aqui no 200 eu posso trazer, eu vou trabalhar com a página 1, que a next page é a página 2, e que eu vou ter um conjunto de vídeos aqui para mim. E aqui já está super ok, aqui para mim também. Beleza? Opa! Nesse endpoint aí, não faz muito sentido ter o ID. Você tá buscando por todos os vídeos e quer fazer um filtro ali. Ah, é verdade, pô. Muito obrigado. Eu não tinha colocado isso e depois eu coloquei por algum delírio, porque a gente vai precisar de um get em algum momento, né? Na realidade o get a gente já colocou, né? Que é pra fazer o playback dele aqui Muito obrigado, tá? Eu tinha colocado E depois eu acabei colocando isso aqui Mas... Antes do ponto de interrogação Acho que é gerado Ok, galera Tudo bem com o preciosismo Da barra Sem barra iria funcionar, mas beleza Oi, Zé Perguntando aqui de um ponto de vista de estratégia Por exemplo, numa entrevista O search Ele é um requisito de suporte Funcional Já que você está dando esse detalhamento Do page no search Já que o playback é um requisito code, não vale a pena falar sobre o detalhamento do playback, por exemplo, os chunks de vídeo, os pedaços de vídeo, como é que vai vir uma parte depois da outra, como é que essa parte vai ser dividida? Então, na realidade, o que acontece? o que acontece? O playback do vídeo, o processo de recebimento de chunks, ele é bem diferente em relação à comparação do search. Por exemplo, no caso do vídeo, os chunks vão sendo recebidos automaticamente por conta que o browser faz isso. Entendeu? Então, nesse caso aqui, eu não preciso de ter todas as informações de chunks e coisas importantes. Se eu achar que existem coisas relevantes aqui, eu posso até colocar. Por exemplo, vamos detalhar alguns pontos importantes. O que é importante em relação a eu trazer o vídeo? Em relação a dados importantes? A URL que o vídeo vai trabalhar? Legal? E normalmente essa URL normalmente ela é baseada num manifesto onde tem todos os chunks que vão ser lidos ali pelo vídeo eu não sei se em algum momento vocês já trabalham com os vídeos, mas normalmente a gente tem alguns arquivos M3 ou 8 ou coisas desse tipo. Ou MPD, não sei se vocês já viram esses tipos. Esses caras aqui são manifestos onde aqui dentro eu tenho a URL de todos os chunks que esses vídeos têm. Mas esse manifesto é gerado para o processo de encoding do vídeo. Então, sim, no playback, eu posso detalhar. Nesse caso aqui, o ponto mais importante, na minha opinião, seria a URL onde o vídeo vai trazer. E, obviamente, eu posso trazer as informações, o nome do vídeo, na descrição dos vídeos, ou os outros metadados que eu vou ter desse cara aqui. Vai depender muito mesmo de como que está rodando a entrevista. Por exemplo, você fez essa pergunta para mim, eu fui e adicionei esses pontos aqui para vocês. O entrevistador, de cara, na hora que eu não coloquei nada, ele já poderia ter falado. Mas que dados são importantes eu retornar? Ah, são esses. Opa, então estou colocando eles aqui agora. Alguém me cobrou, eu estou colocando. É sempre importante falando sempre em voz alta. Então isso aí é um ponto importante. Tem gente que colocou aqui o JP. Não sei se eu concordo em falar apenas daquilo que você tem propriedade. Isso pode trazer uma visão de limitação. Às vezes é melhor você dizer, existe isso, existe aquilo, contudo escolher essa solução, porque eu conheço em detalhes. JP mais ou menos, tá cara? Vamos lá. Tem dois pontos importantes. Você pode falar que, olha, a gente vai trabalhar com Elasticsearch, a gente vai fazer isso, a gente vai fazer aquilo. E esse momento, ele vai acontecer no System Design na hora que você for fazer o desenho. O ponto mais importante de tudo é, você tem que ter ciência, e se você falar algo, isso aí pode vir, entre aspas, contra você. Por exemplo, se eu me sinto super confortável a trabalhar com Search, eu vou colocar aqui um monte de informação, porque eu quero, na realidade,ável a trabalhar com o search, eu vou colocar aqui um monte de informação, porque eu quero, na realidade, que a pessoa pergunte mais e se aprofunde, porque eu tenho certeza que eu vou conseguir trabalhar. Os pontos que eu não tenho uma profundidade maior, eu vou trabalhar de uma forma ligeiramente genérica. O que significa ser ligeiramente genérico? Ah, eu vou colocar que eu vou trabalhar com um banco de dados de coluna larga. O que significa ser ligeiramente genérico? Ah, eu vou colocar que eu vou trabalhar com um banco de dados de coluna larga. E o cara provavelmente vai perguntar, por que você está usando um banco de dados relacional e nesse caso você está trabalhando com um banco, sei lá, no SQL? E você vai explicar os conceitos básicos de diferenças. Se o cara quiser se aprofundar em algum banco de dados no SQL que você vai utilizar, você pode falar, olha, eu nunca trabalhei com esse banco de dados, mas eu sei que ele funciona assim e assim assado. O que a gente tem que tomar cuidado é que cada brecha que a gente dá, a gente está simplesmente alimentando a possibilidade da pessoa fazer perguntas mais específicas com aquele assunto. Então, a minha recomendação que eu sempre vou dar é, sempre para mostrar o seu portfólio, tente apresentar e trazer mais elementos daquilo que você já tem mais conhecimento. Porque você pode ter certeza que vão ser trazidos, vão trazer pra vocês pontos que você não citou. Então, já que eu sei que vai vir, vamos dizer, chumbo grosso pra frente, onde pessoas vão trabalhar, vão trazer, vão me cutucar com coisas que eu não citei, eu já não vou citar coisas que eu já não tenho tanta confiança pra responder, tá? Então, é aquela parada. Se você coloca, você já está pedindo que a pessoa pergunte para você sobre aquilo é basicamente isso que vai acontecer você colocou é como você dizer pode perguntar pra mim sobre isso quando você não coloca né a o que vai acontecer mas o site como é que funciona e aí o entrevistador ele vai te colocar ele colocar, ele vai começar a te provocar. Então, basicamente, é assim. A gente tem que conseguir equilibrar, e isso vai depender muito do contexto do jogo de cintura. Eu vou dar um exemplo aqui para vocês, tá? Vamos imaginar que, quem concorda comigo, que a maioria das coisas hoje em dia a gente consegue sempre fazer com banco de dados relacional muita coisa hoje em dia a gente consegue mas se eu colocar a minha solução 100% com banco de dados relacional aí talvez eu esteja realmente me limitando e o cara falou, cara, esse cara nunca ouviu falar em banco de dados sei lá, orientado a documentos porque ele só colocou relacional aqui aí eu digo que você está realmente forçando um pouco a amizade, porque você não está trazendo outras opções provavelmente, dependendo do cargo que você vai aplicar, o cara vai falar isso. Cara, é só banco de dados relacional? Não tem outro tipo de banco de dados que funcionaria melhor? Quando que você usa um? Quando que você usa outro? Então, existem algumas perguntas que sempre vão vir. Por exemplo, banco de dados é uma pergunta que vão fazer. E você pode colocar relacional em tudo? Pode. Naquele contexto, vale a pena ser relacional para tudo? Dependendo, até vale. Mas, às vezes, a gente pode ter outras opções. Então, vale a pena a gente sempre tentar dosar esses tipos de coisa. Porque a ideia aqui também é você conseguir mostrar a abrangência do seu conhecimento, mas também não comprometendo a sua entrevista no aspecto de, eu vou colocar algo que eu definitivamente não tenho ideia de como funciona. Eu falei do search por quê? Porque aqui não é um... Aqui provavelmente essa parte de search vai ser com um banco de dados que não é relacional. E se eu estou começando a trazer já para esse lado, passando diversos detalhes, eu já estou tentando partir do princípio que me pergunta mais sobre bancos de dados de search. É como se fosse uma piscadinha de olho. Quando você está afim de alguém, você de search. É como se fosse uma piscadinha de olho. Quando você tá afim de alguém, você dá aquela piscadinha de olho. Ou seja, eu tô pedindo. Pode vir, que eu vou responder mais sobre isso. Beleza? Então, temos que tomar cuidado pra gente não... Aquela história, sabe? O peixe morre pela boca. Então, a gente tem que tomar um pouco de cuidado com isso aí. Mas, assim, é muito feeling. Eu sou uma pessoa que eu tento trabalhar da forma mais segura possível. DRM. A gente vai precisar de endpoint de DRM aqui também. Então aqui no nosso caso, provavelmente eu vou ter que ter a geração da licença, né? Pra que a pessoa consiga ver o vídeo. Então eu vou colocar aqui DRM Generate License por exemplo e aqui eu vou dar um post no meu vídeo ID DRM barra generate, por exemplo. Ok? Posso fazer alguma coisa desse tipo ou apenas colocar um barra DRM. Depende muito de como você quer organizar. Muitas vezes, quando você tem ações específicas do que você pode colocar, aqui você pode colocar uma action dentro da barra. Mas, aqui eu estou gerando action dentro da barra, tá? Mas, aqui eu estou gerando uma licença aqui de DRM. E aqui, a minha licença, eu vou responder aqui que eu fui, que eu consegui criar a licença e etc. Beleza? Agora, eu preciso também, em relação a DRM, fazer a autenticação daquela licença para ver se aquele usuário consegue assistir aqueles vídeos, certo? Então, aqui nesse nosso caso, o que a gente vai fazer no final das contas? Eu vou colocar DRM Auth de autenticação aqui para mim. Onde aqui eu vou ter um GET, aí eu vou ter o vídeo, ID, DRM, e eu posso passar, por exemplo, o user ID aqui pra mim. E aí eu vou ter o meu resultado aqui também, com 200, caso o cara tenha sido autenticado aqui para mim. Galera, se a gente conseguir entender esses quatro pontos principais, a gente começa a perceber que o que eu prometi aqui é o que eu estou cumprindo os meus endpoints. é o que eu estou cumprindo os meus endpoints. Então, isso aí é um ponto importante. Esse aí é um ponto importante que a gente tem que fazer. O que eu falei que eu ia entregar, eu estou entregando aqui. Aqui está o meu design de API. E aí vai chegar aquela hora esperada que são os desenhos. Que é realmente fazer o nosso system design e aí a gente sempre tem que pensar no nosso caso aqui, nós temos alguns pontos importantes que é o seguinte eu vou ter duas formas de visualizar o meu system design a primeira forma de visualizar é quem vai fazer o upload do vídeo, o? O usuário que é administrador. A gente até colocou na nossa modelagem do dados lá, quem é o nosso camarada visualizador ali, no nosso caso, tá? Galera, eu tenho alguns pedaços aqui do System Design pra não ficar gastando uma hora desenhando aqui na frente de todo mundo, tá? Então existem, eu pré-planejei esse System Design aqui pra gente não ficar, inclusive, desenhando, né? Detalhezinho por detalhezinho aqui. Eu vou trazer algumas coisas aqui que faz sentido e eu vou colando nos pedaços aos poucos aqui pra vocês. Que vai ser o seguinte, deixa eu ver se eu consigo trazer aqui. Beleza. Vamos ver se eu consigo colocar. Primeira coisa que eu estou colocando aqui já de cara para a gente, é o que? Vocês estão conseguindo enxergar bem aqui? Sim. Está de boas, né? Sim. Bom, o que eu recomendo sempre aqui pra vocês de forma geral toda vez que vai bater uma conexão falar que vai cair num API Gateway ou normalmente num Load Balancer por que que eu já tô colocando aqui de cara um API Gateway? porque o API Gateway por padrão, ele já pode ter autenticação, ele já tem Rate Limiting tá? ele já tem diversos de outros recursos. Então, quando alguém fizer perguntas pra mim referente a isso, eu já falo, olha, o API Gateway tá cuidando disso aqui pra mim. É basicamente isso que eu tô falando. Então, eu já consigo de me livrar, eu consigo já me livrar de bastante coisa. Tá? Então, o normal, e o API Gateway, ele também vai conseguir mandar os nossos recursos conseguindo trabalhar. Primeira parte do serviço que a gente precisa fazer, upload. Então, upload é uma das coisas extremamente importantes que a gente vai precisar ter. Então, o que eu posso fazer nesse momento? Eu posso colocar que eu tenho um serviço específico só para fazer upload de arquivos. Então, eu vou colocar aqui, ó, um upload service, onde eu vou receber as minhas requisições. Então, o cara pediu pra fazer o upload, eu simplesmente vou colocar aqui esse cara num upload service aqui pra mim. Tá? Então, recebi a chamada, deixa eu diminuir essa fonte aqui. Eu tenho esse cara aqui do meu upload service pra eu trabalhar tá? deixa eu diminuir essa fonte que ficou grande pra caramba, upload ok? mandei essa solicitação pelo upload, e aí a coisa vai começar, tá? umas coisas importantes, pessoal. Toda vez que eu for trabalhar com o upload, esses dados, eles vão cair necessariamente em algum lugar. Então, quando a gente tá falando de vídeos, onde eu guardaria o dado do meu vídeo? Onde eu guardaria o meu vídeo bruto mesmo? Onde que eu subiria do meu vídeo? Onde eu guardaria o meu vídeo bruto mesmo? Onde que eu subiria esse meu vídeo? Hein? No S3. No S3, eu acho que é o melhor. Legal. Tá, legal. Então vamos partir do princípio que é um... Que é um bucket, tá? Então vamos lá. Eu preciso guardar o arquivo que eu vou subir em algum storage. Então, eu estou colocando aqui um bucket, não interessa qual cloud provider seja aqui. Agora, o lance é o seguinte, vamos deixar uma coisa mais homogênea, vamos partir do princípio que a gente está trabalhando, sei lá, numa S3 da vida. Eu tenho algumas dificuldades aqui, que é o seguinte, quando eu faço o upload, o meu arquivo de vídeo vai para esse meu serviço, e esse serviço sobe o vídeo aqui? É isso que acontece? Eu acho que o ideal seria assinar uma URL do S3. Show de bola. Então já teve gente aqui que já matou essa parada. Eu tenho que mandar os dados do vídeo, obviamente. Mas uma coisa que a gente realmente vai precisar é assinar uma URL. Uma vez que eu assino uma URL aqui... Alguém muta um microfone aí que tem alguém... Show. Então é o seguinte, a gente tem URL, então o que a gente pode colocar aqui é colocar uma forma de que quando o upload também aconteça, eu vou gerar aqui uma URL assinada, muito bem colocado, eu não lembro quem falou, mas... Eu vou colocar aqui uma URL assinada, eu vou colocar até aqui, ó. Pre-signed URL. Eu fazendo isso, eu faço com que, além de eu mandar os dados do upload, esses dados, eles sejam enviados direto pro bucket sem passar aqui por dentro da minha infraestrutura, porque senão a gente já tá bem enrolado em relação a isso. Mas o grande ponto é que na hora que a gente tá trabalhando com o vídeo, né, a gente pode explorar algo um pouco a mais. Por hora, eu vou deixar esse serviço dessa forma e a gente vai adicionando complexidades conforme a gente vai passando. O ponto importante aqui é a gente sempre lembrar qual é o meu objetivo. Volto aqui pra cima. Upload de vídeos. Eu acabei de fazer o upload? Maravilha. Ótimo. Está feito uma feature. O que eu preciso fazer? Playback de vídeos? Então vamos lá. Uma vez que eu tenho o meu vídeo feito como um upload aqui, provavelmente em algum momento eu vou precisar fazer com que esse vídeo ele possa ser acessado por alguém. Ou por exemplo, quando o meu vídeo ele possa ser acessado por alguém, né? Ou, por exemplo, quando o meu vídeo, ele terminar de ser feito o upload, eu posso ter um outro serviço, que é um video service mesmo, que é o cara que vai servir os vídeos pra mim. Então, quando eu acabei de fazer o upload, esse cara manda e fala assim, olha, eu tenho um video service que tá pronto aqui para você. Maravilha! Ou seja, eu consigo de forma geral, ó, resolver meu upload e o meu serviço de vídeo que eu vou trabalhar. Mas, eu tenho uma outra situação aqui. E a minha situação é eu preciso de DRM e eu preciso de search. Então, vamos resolver não sei se vocês estão percebendo a minha linha de raciocínio galera, mas ela sempre está focada nos requisitos ou nos designs dessa API, eu tenho que conseguir cumprir todas as operações e depois eu vou incrementando e melhorando o sistema e conversando com o entrevistador colocando, o entrevistador, colocando, né, o entrevistador, ele sempre vai falar, mas e se isso acontecer? E se isso acontecer? E a gente vai acabando, facilitando um pouco a nossa vida. Então, por exemplo, vamos falar de DRM. Toda vez que eu recebo um pedido de um vídeo, eu preciso cair no meu serviço de DRM aqui para mim. Então deixa eu pegar aqui que esse aqui eu já posso até colocar... Deixa eu colocar aqui. Eu posso colocar aqui um DRM Service. E toda vez que um vídeo pedir qualquer coisa aqui para mim, eu posso fazer o quê? Eu posso falar o seguinte, eu preciso da autorização da licença. TRM Auth Service. Ô Wesley, desculpa atrapalhar aí, eu só não entendi porque essa sequência do upload service vai pra video service. Qual a lógica disso? Eu me perdi. Vamos lá, toda vez que eu fiz um upload de vídeo eu vou comunicar ao meu serviço de vídeo que esse vídeo aqui está disponível a gente vai melhorar essa situação, por quê? porque a gente vai começar a falar de banco de dados a gente vai começar a perceber que cada microserviço tem um banco diferente esses dados precisam ser replicados tá? a gente vai melhorar isso aqui porque esse acoplamento aqui, claramente, ele não é um acoplamento muito legal. Acho que todo mundo concorda comigo, né? Tá? O meu importante aqui é botar o Lego pra funcionar. E daí a gente vai melhorar resiliência, a gente vai melhorar comunicação e tudo mais aqui pra mim. Show? O que que eu tenho que ter aqui também, nesse momento? Eu preciso ter um serviço de busca, né? Então eu vou colocar aqui um serviço de search. Então eu vou colocar aqui, ó, search, serve-se aqui para mim. Beleza? Ok, tem um serviço de search. Do meu outro lado, de forma geral, é que eu estou com a fotinho de todo mundo aqui aparecendo e eu não estou conseguindo enxergar. No meu Search Service, de forma geral, eu posso colocar um outro API Gateway, tá? Ou replicar o que eu já tenho aqui, tá? Eu vou colocar um outro aqui só para ficar melhor a nossa visualização. Mas no final das contas, o que eu estou querendo dizer com isso aqui é Eu vou ter um usuário, o viewer, o espectador Eu gostei muito do espectador, cara Eu vou ter o meu viewer, meu espectador aqui querendo realizar as ações Quais ações que esse espectador pode, querendo realizar as ações. Quais ações que esse espectador pode querer fazer, galera? Assistir. É um show de bola. É um show de bola. É isso aí. Então, ó, aqui eu vou colocar as operações que eu vou fazer. Então eu vou fazer o playback do vídeo e eu vou fazer o search, certo? Porque são exatamente os recursos que eu tenho, que é o que eu coloquei lá nos meus requisitos. Perceba como é importante aquela definição de requisito, que aquilo vai cair o tempo todo para a gente. Quando eu precisar do search, eu vou bater aqui e vou realizar a operação de search. Correto? Quando eu precisar fazer o playback, eu vou bater aqui no meu video service para eu fazer o meu playback. Beleza? Agora, o que está faltando aqui, pessoal? Tem um dos... Tem um das nossas APIs aqui que a gente não está implementando. Gerardo, desce. Gerardo? O DRM não está ligado no playback do usuário, né? É a autenticação. Não, a autenticação não faz parte dos nossos requisitos. DRM, a autenticação do DRM. Perfeito. Está a autenticação não faz parte dos nossos requisitos. A autenticação está no gate. Perfeito. Está a autenticação do DRM aqui? Isso, a gente tem na realidade aqui, o DRM Service é Generate License. License, ele vai gerar a licença para cá, mas para eu conseguir, Generate License barra autenticação. Eu vou colocar o Generate License barra autenticação. Eu vou colocar o Generate License. Mas o que vai acontecer aqui para a gente? Toda vez, e a gente tem o Alt também que ele vai bater aqui. Mas para isso aqui acontecer, essa DRM deve estar plugada em algum lugar. Então como é que a gente começa a pensar daqui para frente? Vai depender muito de como o entrevistador está conduzindo. Nesse momento, ele pode começar a fazer algumas perguntas, por exemplo. Qual banco de dados eu vou utilizar? Eu subi o vídeo inteiro aqui. Como que a pessoa vai assistir esse vídeo inteiro? Eu acho que começa pelas funções mais básicas, né? Como que eu assisto esse vídeo, galera? Eu fiz o upload do vídeo. Esse vídeo vai ser enviado... Eu vou baixar o vídeo inteiro no meu computador para assistir? Nossa. Não. ele vai ser enviado... Eu vou baixar o vídeo inteiro no meu computador pra assistir? Não. Você vai fazer o streaming, né? Vai o chunk, né? Tem que fazer os chunks. Isso, então vamos lá. Então, pra fazer isso, o que eu vou fazer é o seguinte. Eu vou colocar aqui, tá? E isso aqui eu já tenho desenhadinho pra não ficar... Pra ficar mais fácil, inclusive, de ver. Opa. Dá pra perceber que tem hora que não dá pra copiar e colar desse cara. Vamos ver se ele vai dar, senão eu desenho ele aqui. O que que normalmente acontece com serviços de vídeo de forma geral, tá você cria um pipeline pra esse vídeo ele ser processado e ele ser convertido em diversas formas, tá e o que eu tô querendo dizer aqui pra ele vai ser o seguinte, toda vez que eu for fazer o upload aqui pra ele, vai ser o seguinte toda vez que eu for fazer o upload aqui pra mim eu vou botar esse vídeo num pipeline e esse pipeline, ele vai pegar os chunks que eu recebi na hora dos uploads ele vai rodar regras de negócio, ele vai rodar filtros ele vai fazer o encoding, ajustar os codecs a gente pode ter diversos processos, eu não sou um super especialista de vídeo então o que eu sei é que nunca ninguém vai subir um arquivo direto provavelmente a gente vai separar eles em chunks pra subir, provavelmente existem diversas regras, sei lá deve ter filtros, deve ter tagueamento dos vídeos, deve ter verificação de conteúdo inapropriado deve ter filtros, deve ter tagueamento dos vídeos, deve ter verificação de conteúdo inapropriado, deve ter um trilhão de coisas que esses vídeos devem rodar, eu estou colocando aqui como regras de negócio. E encoding, que eu sei que vai ter que fazer a transformação dos vídeos para utilizando um determinado codec, a gente tem os containers dos vídeos para os diversos formatos e tudo mais. Então, eu estou colocando isso que ele vai rodar isso no pipeline e quando esse cara ficar pronto o que vai acontecer? eu vou devolver esse meu amigo aqui para um bucket, porém o que acontece? na hora que eu vou realizar esse processo aqui eu tenho que gerar a minha chave desse vídeo pra minha DRM. Então, esse cara, em algum momento, ele vai bater desses dois lados. Vou até botar as setinhas dos dois lados pra cada vez ficar isso aqui mais claro, tá? Ok? Então, quando eu gero o vídeo, esse vídeo tem que ser carimbado com a licença minha da DRM aqui também, tá? então eu vou colocar o alt da DRM aqui na hora que eu vou fazer a geração do meu vídeo agora ainda falando sobre upload tem mais alguma coisa em relação ao upload pra subir o vídeo aqui? aparentemente não. Acredito que por enquanto está aceitado, porque eu já consegui fazer todo o meu processo do meu vídeo, coloquei meu vídeo aqui no bucket de novo, para eu conseguir trabalhar com ele, gerei uma URL pré-assinada para eu conseguir fazer o upload desse camarada aqui. Agora, um dos requisitos não funcionais é fazer com que o vídeo tenha baixa latência. Uma das formas de fazer com que ele tenha baixa latência é converter o vídeo em segmentos pequenos, em diversas resoluções, para que, dependendo do dispositivo que a pessoa acesse, ele consegue pegar uma resolução pior, piorada do vídeo, mas ao mesmo tempo ainda assim o cara consegue assistir o vídeo. Porém, o que mais que eu poderia colocar para fazer com que eu acesse o vídeo pra que eu consiga acessar o vídeo com uma latência ainda menor, galera. Um CloudFront na minha... no meu desenho, um pouquinho CloudFront. Isso, que é uma CDN no final das contas, né? CDN. Show? Então, caras, eu acho que... Deixa eu pegar aqui um cara de uma CDN ele pega aquele S3 que subiu e espalha é isso aí então esse cara vem pra cá, né então toda vez que o cara quiser fazer, assistir um playback do vídeo, o que vai acontecer no final das contas é que ele vai pegar os dados, mas na hora de ele assistir o vídeo em si, esse dado vai vir de uma CDN. Todo mundo aqui sabe o que é uma CDN, galera? Alguém não sabe o que é uma CDN? Eu não sei. Tá, CDN significa Content Delivery Network. Basicamente, é... são locais que você vai replicar o seu dado para que quando alguém acesse esse dado, ele seja puxado do local mais próximo do usuário. Então, um exemplo simples. Se você está assistindo a Netflix de São Paulo, provavelmente o vídeo que você está baixando deve estar vindo de algum data center mais próximo de você de São Paulo. Eu moro nos Estados Unidos, provavelmente o vídeo que eu estou baixando ele está vindo de algum local dos Estados Unidos. Então, a ideia básica da CDN é, toda vez que vai subindo dados aqui, ele vai sincronizando com a CDN e vai replicando isso pra tudo quanto é lugar, para que você acesse o vídeo ou o conteúdo do local mais próximo onde você tá. Então, eu tô mais próximo do usuário com o meu vídeo, e ainda o meu vídeo, nesse caso, ele atende múltiplas resoluções. Então, eu estou mais próximo do usuário com o meu vídeo e ainda o meu vídeo, nesse caso, ele atende múltiplas resoluções. Então, isso é uma forma de eu conseguir reduzir a latência. Fez sentido? Fez sim. Show? Então, isso aqui é bem comum. A AWS tem um serviço que chama AWS CloudFront, mas a gente tem diversos players de DRM no mercado, um dos mais conhecidos aí é a Kamae, não sei se vocês já ouviram falar eles tem assim, nível muito grande de granularidade, por exemplo, se você tá usando a Kamae em São Paulo a chance de você tá baixando um vídeo ou algum conteúdo do post do seu bairro é muito grande, porque eles conseguem fazer diversos acordos com provedores locais. Cara, é uma estrutura muito grande de pontos de presença que essas CDNs acabam tendo, tá? A Netflix tem appliances que eles colocam em provedores pra fazer CDN nos provedores. Você acessa direto do seu provedor, praticamente. O resumo da história é o seguinte, galera. Eles trazem um hardware com todos os vídeos mais acessados daquele momento, naquela sua região, e vai lá e fala, ó... E o provedor, nesse caso, agradece, cara. Porque senão o provedor, ele tem que ficar gastando uma banda gigante pegando vídeo de um lado pro outro. Então os caras botam isso rodar local, cara. É um negócio muito maluco. E eles fazem muitas pesquisas do tipo em São Paulo ou no Brasil, quais são os catálogos mais acessados? E daí esses caras, eles priorizam pra colocar nas CDNs ou nos pontos de presença mais fortes. Bom, tô conseguindo diminuir o tamanho do vídeo, de acordo com... Wesley, qual foi o provedor de CDN que você falou? Akamai. É, A-K A-A-K A-K-A-M-A-I. Beleza, valeu. Show. Então, a gente já está conseguindo Fazer o playback, galera Eu estou feliz aqui em relação ao nosso playback De forma geral Agora, a gente tem alguns pontos Aqui importantes Para a gente conseguir trabalhar Que é o seguinte Eu devo imaginar Que ainda para eu fazer meu playback, aqui nesse meu video service, ele é um microserviço bem crítico, é um serviço bem crítico, vocês concordam comigo? Todo mundo está dando paulada nele o tempo inteiro. Ok? Sim. E esse camarada, ele, obviamente, ele tem um banco de dados, onde ele tem todos os dados, obviamente, ele tem um banco de dados. Onde ele tem todos os dados, deixa eu colocar aqui um, vou colocar aqui, como vocês falaram que vocês querem. Só banco de dados relacional, a gente vai trabalhar aqui na Netflix. Deixa eu colocar aqui. Então, vamos imaginar que eu tenho aqui um banco de dados relacional mesmo, onde eu tenho as informações dos meus vídeos, por exemplo. Agora, toda hora eu ficar batendo nesse banco de dados, aqui talvez não faça muito sentido. O que eu poderia fazer para me ajudar aqui? Cash. Cash. Redis. Cash Cash Cash Então o que a gente pode Show Eu vou colocar aqui que a gente tem Um banco de dados De cash Pra nos ajudar aqui com esse cara aqui também Ok? Ou seja, eu tenho um banco de dados em cache e eu tenho por exemplo um banco de dados relacional, depois a gente pode até discutir se esse cara deve ser relacional ou não. Mas aqui eu já estou meio que dizendo, caras, um cache já vai me ajudar muito e etc. Qual um banco de dados de cache que vocês conhecem que funcionam muito bem? Redis. Redis, certo? Ok, é uma opção. Uma outra coisa importante que eu sempre recomendo é tente estudar um pouco de forma razoável, por exemplo, você vai falar de banco de dados em cache. Vou perguntar, você vai falar Redis. Aí eu começo a perguntar pra você como que o Redis funciona? Redis ele é multi-thread ou ele é single-thread? como que ele grava os arquivos do cache? se ele reiniciar, o que que acontece? ele mantém estado ou não mantém estado? então é importante sempre também, a gente, nesses momentos, inclusive antes do System Designs, se eu vou falar que eu vou trabalhar com banco de dados em cache, eu tenho que estar um pouco sujeito a responder um pouco sobre como funciona um banco de dados em cache. Então, somente para a gente pensar nesse ponto aqui. DRM também precisa de banco de dados um cache tá então somente para a gente pensar nesse ponto aqui DRM também precisa de banco de dados com certeza ela precisa também de um banco de dados porque ela vai fazer o por exemplo o controle das licenças que ela gerou por exemplo né então eu posso colocar aqui que a minha DRM também tem um banco de dados o search service tem um banco de dados banco de dados o search service tem banco de dados e tem banco de dados certeza certeza né e aqui eu vou colocar um banco de dados focado em busca por exemplo um elastix search e nesse momento é aquela história galera o entrevistador pode falar como é que funciona um banco de dados, qual banco de dados de search você usaria, Elasticsearch, você já trabalhou? Aí vai depender muito do seu nível. Você fala, cara, eu sei que o Elasticsearch ele faz buscas, eu sei que ele vai ajudar, mas eu nunca trabalhei com Elasticsearch. Paciência é o que vai ser falado e acabou, você não vai mentir. Então, é sempre importante, e a dica que eu dou para vocês é, dê uma estudada como é que funciona um Elasticsearch, dê uma estudada como é que funciona um banco de dados, um Redis da vida, tá? Isso sempre vai ajudar, mesmo que você nunca tenha trabalhado especificamente com esse banco de dados. Ter o básico de como esse cara funciona é bacana. Ah, o Elasticsearch, você consegue criar uma espécie de esquema, que é um mapeamento, ele disponibiliza uma API REST, por baixo dele ele trabalha com Apache Lucene, mas o Elasticsearch tem diversos tipos de estrutura, então ele tem o cara que ele trabalha como coordenador, eu tenho o cara que é responsável só para a parte de storage, eu tenho o cara que é o worker que vai fazer as buscas nos meus índices, que vai trabalhar com isso, tem o cara que junta as informações dos vários shards que eu tenho. Então, assim, vale a pena vocês sempre tentarem se aprofundar um pouco mais nesses bancos de dados porque vão começar a cair. Por exemplo, o Redis. Ah, é um banco de dados que trabalha em memória. O que acontece se eu perder o meu cache? Ah, como é que o Redis funciona? Quais são os tipos de dados? Fora o cache normal dos dados, ele tem banco de dados em vetor? Ele trabalha com PubSub? É sempre interessante você saber um pouquinho a mais de como esses caras acabam trabalhando, tá? O que que tá faltando aqui, pessoal? Que ainda a gente pode perceber que tá... que pode gerar uma espécie de um gargalo aí. Comunicação ali do upload service com video service. Esse aí ficou incomodando todo mundo, né? Fala a verdade. Todo mundo coçando pra falar. Ele fica coçando ali, né? Uma coisa tão direta assim, né? Galera, assim... Gera uma dependência, né? Gera um vínculo ali. É, então. E normalmente quando você coloca algo muito direto ao outro, o que você tá dizendo é que ele tem uma dependência muito forte e essa dependência... O que eu estou dizendo aqui é que eu tenho que fazer todo o upload e em seguida mandar esse cara numa tacada só. E se esse vídeo serve, se estiver indisponível, ferrou, né? Então, o que eu posso fazer aqui no meio dessa história para facilitar um pouco a vida? Eu posso... Outra coisa, por favor, tome cuidado novamente. Cara, coloque uma fila e aí espere o que vem, quais são os mecanismos de fila. Se você falou cáfica, aí eu já vou começar. Poxa, legal cáfica, cara. Como é que funciona o Kafka? Como é que funcionam as partições? Como é que ele funciona de forma distribuída? Como é que o Kafka faz? Qual é o ecossistema? O que é o Kafka Connect? O que é o K-Circle DB? E daí vai longe novamente. Então, sempre tente tomar cuidado em falar o nome da tecnologia. Inicialmente, se você já conhece o Kafka, talvez seja melhor você falar aqui, cara, eu vou colocar uma fila, tá? Wesley, eu ainda estou muito perdido em saber o que é que esse upload service está falando com o video service. É o que ele tem que informar para o video service? Que eu tenho o video pronto. Mas isso ele não poderia simplesmente colocar dentro da base? Ele precisa informar para o video? Com certeza, cara. Só para vocês terem cada vez mais ciência, os bancos de dados em serviços tão separados eles são isolados, tá? esse upload service ele tem o próprio banco de dados dele tá? na prática, galera esses sistemas, eles são tão grandes que assim, é quase que impossível em sistemas dessa escala, um sistema de upload acessar diretamente um banco de dados de um serviço que não é dele. Os bancos de dados, sempre, de forma geral, eles não são compartilháveis. Eles têm que rodar porque a necessidade de base de upload aqui para mim, ela é diferente da necessidade do video service para banco de dados. Esse banco de dados aqui, ele tem um nível de responsabilidade para atender esse cara. E esse cara aqui, ele não conhece todas essas minhas necessidades, porque isso aqui é mantido para uma outra equipe, para um outro lado da empresa, com outros desenvolvedores, então normalmente normalmente, cada serviço ele é independente e tem o seu próprio banco de dados o que ele tem que fazer com certeza, com certeza o que mais existe o que mais existe no mundo hoje em dia é, são as informações duplicadas, tá é a parte mais informações duplicadas, tá? É a parte mais comum de tudo, tá? As informações, elas são duplicadas, e não é um pouco, tá? É duplicado pra caramba. Por exemplo, o meu search service, né? Quando um vídeo fez o upload, aqui também, isso aqui tem que ser atualizado no meu search também. O que que eu vou ter que fazer nesse caso? Esse meu cara, foi até bom falar, foi até bom a gente falar sobre isso, ó. Esse cara aqui, ele tem que atualizar, ele tem que consumir essa fila também. Foi até bom a gente colocar, porque ele também é sincronizável. Né? E toda vez que o vídeo serve-se mudar qualquer coisa em relação ao vídeo, eu também posso colocar isso numa fila para atualizar em outros lugares. Por que eu não estou colocando isso? Porque eu não gerei nenhum endpoint de update vídeo. Simplesmente por conta disso. Se eu tivesse colocado, aí eu já ia falar, o Video Service fez uma atualização e isso vai replicar pro search service. Aí eu colocaria provavelmente numa fila onde o search service iria ler. Tá? Então, obviamente que na prática, o video service provavelmente ele faria alguma coisa desse tipo. Mas, eu coloquei aqui? Não. Então eu não vou fugir aqui mais desse escopo. Tem mais alguma coisa? Desculpa, isso muda toda a minha visão porque eu iria tentar resolver isso no banco de dados. Tipo, se eu precisasse ter dois bancos eu ia replicar. Cara! O upload service é quem iria inserir os dados ali no RDS dele e isso ia ser replicado para o outro banco, porque o video service iria ler, eu iria tentar resolver dessa forma, ao invés de pedir o video service para consumir a fila. É interessante, cara, sabe por quê? Porque é o seguinte, os dados que a gente tem aqui do upload service, não necessariamente são os dados que eu preciso no video service. Então, uma coisa que é interessante, galera, em falar em relação à replicação de dados. Existem, hoje em dia, dados que são muitos replicados mesmo. Mas eles são normalmente replicados, entre aspas, pela metade. Eu vou dar um exemplo aqui no Seja Vídeo que fique um pouco mais simples. Imagina que eu tenho aqui no meu e-commerce a área de produto. E no produto eu tenho o nome, eu tenho o fabricante, eu tenho o lote, valor de compra sei lá é país do fabricante um monte desses dados aqui certo? a área aqui que tá contratando pedindo a parte de produto é uma agora imagina que eu tô no catálogo do imagina que eu estou no catálogo do... Imagina que eu estou no catálogo da loja. Eu preciso saber o valor que eu comprei esse produto? Não. Preciso saber o lote? Preciso saber o país do fabricante? Não. Mas esses três informações, vamos dizer aqui, eu preciso. Então, o que acontece? Eu tenho um banco de dados aqui de produto, da área de produto, e eu tenho um banco de dados aqui de catálogo. Toda vez que um novo produto for criado, o que vai acontecer? Esse cara vai entrar numa fila, nesse caso, uma fila P de produto os dados vão ser enviados pra cá e o cara do catálogo ele vai ler os dados mas ele vai guardar no banco só o que importa pra ele então os dados são replicados mas eu só tenho os dados do domínio que eu vou trabalhar porque não faz sentido eu ter o valor de compra no meu catálogo, porque meu catálogo não precisa disso tá, então isso aqui ó, é o que move o jogo de aplicação enterprise os bancos, eles são em todos sincronizados o tempo todo é só desculpa lá só pra terminar rapidinho. Então, aí, eu teria que me preocupar também, por exemplo, se eu faço uma alteração no nome do produto, por exemplo, eu vou ter que mandar essa atualização e vou ter que atualizar do lado de lá. Então, se eu tenho dois microserviços e eu estou atualizando o microserviço A, eu também tenho que me preocupar que o microserviços e eu estou atualizando o microserviço A, e eu também tenho que me preocupar que o microserviço B ele entenda aquela alteração. Então, agora eu não me preocupo mais em ficar cuidando disso no banco de dados, eu me preocupo com os microserviços e garantir que eles sabem conversar a mesma língua. Exatamente. Qualquer alteração que eu precise, porque daí essas filas ou tópicos, Aí essas filas ou tópicos, do jeito que você queira chamar, elas ficam escutando e falam assim, eu tenho interesse em produto. Qualquer coisa que tiver de produto, manda aqui que eu leio e eu atualizo no meu banco de dados. Se eu não achar o produto, eu crio. Se eu achar o produto, eu atualizo com as informações que você mandou, por exemplo. É o banco update, o first time do banco que faz isso automático. Eu fiz assim, o ARP, a gente tem até custo de insumo, mas o e-commerce a gente não tem esse tipo de dados. E a gente tira a carga do ARP que trabalha pra caralho e o e-commerce tem outro banco com os dados que diz respeito a ele. É bem essa pegada. E o mais importante de filas aqui é que se esse cara estiver indisponível no momento, quando ele voltar ele lê a fila e ele não vai perder dado a fila é uma forma de você manter resiliência mesmo que você tenha problemas de disponibilidade quando esse video service voltar ele vai ler da fila e ele vai continuar processando eu não tenho perigo de na hora que o upload mandar informação pro meu server, se o meu server estiver fora e eu perder essa informação. Então, a fila, ela garante esse nível de resiliência. Tinha alguém que tava querendo perguntar algo? Era justamente sobre a resiliência que eu ia perguntar, né? Se tem como garantir isso, se tiver off ali. Aí acabou o senhor respondendo. Tem sim. Se você está trabalhando com filas, você tem como garantir resiliência. Agora, o importante é você entender qual é o nível de resiliência que você tem utilizando filas. Como assim? Vou dar um exemplo. Se você está trabalhando com a parte cáfica, eu tenho como mandar a mensagem e garantir que você receba a mensagem pelo menos uma vez, mas isso pode fazer com que você receba a mesma mensagem mais de uma vez existem formas de quando eu envio, eu mando eu garanto que eu mando a mensagem pelo menos uma vez, mas não necessariamente que você vai ter garantia que você recebeu, então existem conceitos de garantia de entrega e garantia de recebimento. E quanto maior é o meu nível de garantia, maior é a carga computacional que você vai usar. Entende? Então, você sempre tem que conseguir equilibrar. Eu vou dar um exemplo no Apache Kafka. Você tem a opção de... O Apache Kafka trabalha com várias máquinas. Deixa eu rapidinho desenhar para a gente acabar a aula, galera. Mas o Apache Kafka, imagina que eu tenho um broker 1, eu tenho 2 e eu tenho o 3 aqui. e eu tenho o 3 aqui o que que acontece aqui nesse cara? vamos imaginar que esse broker 1 ele é o líder, no momento o que que acontece? na hora que eu mando uma mensagem pro líder tá? o que que pode acontecer nesse momento? no momento que eu mandar essa mensagem, esse meu líder cai e daí? se ele caiu, o que pode acontecer nesse momento? no momento que eu mandar essa mensagem, esse meu líder cai e daí se ele caiu o que vai acontecer? ele não vai receber a mensagem, eu perdi a minha mensagem então, aqui eu posso falar o seguinte eu quero uma garantia de entrega que o meu broker fale que tá ok se ele não falar que tá ok eu vou reenviar essa mensagem pra não ter perigo de cair mas o que pode acontecer? na hora que esse cara confirma essa mensagem ele deu um ok mas na hora que ele fez isso ele travou e ele teve um problema o HD dele queimou, vamos imaginar ok? esse cara queimou e na hora que ele queimou, o que acontece? Eu perdi a mensagem. Mas, por padrão, os brokers, o que ele faz? Eles se sincronizam, certo? Então, o que eu posso pedir? Um outro tipo de garantia mais forte. Eu posso falar, olha, mandei para o broker. Só me fala que se tá ok quando ele terminar de sincronizar pelo menos com duas réplicas, aí ele fala, ok, sincronizei aí eu tenho certeza absoluta que mesmo que o meu líder caia, essas mensagens elas já tem cópia em outras réplicas e quando essa réplica assumir, eu não vou ter perdido o dado. Então aqui eu tenho uma garantia completa de entrega. Agora, esse tipo de garantia é muito cara, porque eu tenho que esperar tudo isso sincronizar, e vai demorar mais. A primeira garantia que eu coloquei aqui para vocês, ela é ok, porque eu tô garantindo, falando, tô ok. Agora, tem casos que eu falo, eu não quero outra garantia, eu vou enviando fire and forget. Se não recebeu, não recebeu. Quando que pode acontecer? Sei lá, um Uber, eu perder uma posição do cara que eu recebo uma posição a cada 5 segundos, será que vai matar alguém? À que eu recebo uma posição a cada 5 segundos será que vai matar alguém? às vezes não, então de repente eu parto do princípio que nem todas as mensagens vão ser recebidas por questões de disponibilidade entendeu? é mais ou menos essa ideia galera algum outro ponto aqui que está faltando que poderia ser explorado de forma geral em relação a Wesley, me tira só uma dúvida ponto aqui que está faltando, que poderia ser explorado de forma geral em relação a tudo que a gente está colocando? Wesley, me tira só uma dúvida. Sobre o Search Service ali, eu estou vendo que está conectado também na fila. Imagina que tem um filme que ninguém nunca vai pesquisar, mas mesmo assim eu vou ocupar esse espaço ali no banco do Search? Sim. Então se eu tiver, sei lá, um banco gigantesco mesmo assim não tem como eu fazer de uma forma diferente que eu não preciso desse banco aí né? Não cara porque o search ele já serve pra ser gigantesco e a grande diferença dele é que ele consegue buscar muito rápido porque ele é preparado pra isso. Então a forma de indexação dele ela é muito diferente da preparado pra isso. Então, a forma de indexação dele, ela é muito diferente da indexação desse cara. Então, sim, ele é gigante e ele veio e serve pra ser gigante mesmo, cara. É assim que meio que funciona mesmo. Entendi. O que é diferente nesse caso do video service se chamando. Por exemplo, eu mandei rodar os dados de um vídeo. Ah, esse vídeo nunca é acessado, busquei no banco. Esse vídeo é muito acessado, daí eu busco no cache. Agora, no search, não tem muito para onde correr. Porque se ele não está nesse banco, quando a pessoa fizer a busca, não vai existir. É basicamente essa pegada. Então, os dados realmente têm que estar no search. Mas, novamente, somente os dados que interessam para a busca. Não precisam ser exatamente todos os dados. Sei lá, os metadados do vídeo, dos chunks. Cara, não preciso estar isso no search service. Eu posso ter os dados só no manifesto. Tá? Agora, o que mais que a gente poderia explorar aqui, pessoal? Que alguém poderia cair numa sacanagem aqui? Eu fiz uma parte no meu escaledral. Eu coloquei a parte de processamento de vídeo em cluster on-premise. Pensando que eu consigo ter um custo-benefício maior em processamento on-premise. Tá, eu vou dar uma dica aqui pra você, tá? Sempre quando você for colocar em System Design, tente evitar se vai ser cloud ou on-premise, a não ser que caia nessa seara, sabe por quê? Você falou, porque é mais barato. Assim, você consegue me mandar por que é mais barato? Porque o processamento, eu posso ter máquinas melhores e o custo a longo prazo vai se pagar. Você tem toda a certeza do mundo? E se eu tenho um plano, um contrato com a AWS, que ela consegue dar um baita desconto pra mim, no seu on-premise você vai ter que dar data center, você vai ter que ter um monte de pessoal, vai ter que colocar um monte de operação vai ter que ter a conta no hardware, tem depreciação e etc você consegue trazer números concretos dizendo quanto mais barato é esse ou esse nesse contexto de vídeo? o meu ponto que eu tô querendo trazer aqui pra você na realidade não é se é mais caro ou é mais barato. É que quando você coloca uma afirmação, essa afirmação, ela é facilmente, como se diz, rebatida por qualquer pessoa. Eu acabei de falar, eu nem sei na realidade se é mais barato ou se é mais caro. O meu ponto é que eu já joguei um monte de informação pra você e você não consegue naquele momento trazer o dado mostrando que é mais barato, entendeu? É bem essa que acaba pegando, entendeu? A gente sabe que tem muitos casos que realmente um premise é mais barato, agora por exemplo, por que será que a Netflix usa a Amazon pra fazer o transcoding do vídeo utilizando o serviço lá da coisa? Será que a Netflix usa a Amazon pra fazer o transcoding do vídeo utilizando o serviço lá da coisa? Será que a Netflix gosta de gastar dinheiro? Então, às vezes, não é só a grana. Então, tente ser o mais genérico possível de aonde as aplicações, onde aquilo que tá rodando. Porque você consegue ainda dar uma visão de alto nível, que é o que o System Design faz, e se o negócio partir para esse lado, poxa, e serviço é na nuvem? Qual o provedor? Ah, a AWS. Ah, a AWS, então como que é a CDN da AWS? Ah, o CloudFront. Ah, o Storage, a AWS, como que ele chama? Ah, ele chama S3. Ah, legal. E o API Gateway? É da AWS também? Como chama? AWS API Gateway. Ah, e como é que funciona o transcoding? Como é que funciona esse esse, como se diz? Esse workflow? Ah, eu posso usar Step Functions da AWS. Sacou? Ah, aqui o que vai ser? Pode ser um SQS. Opa, pode falar. Perdão, desculpa te cortar aí. Nesse quesito, é interessante a gente sempre optar por estratégias de outras empresas, como o AWS, o SQS, o S3 e tudo mais, ou a gente pode citar abordagens que a gente faria na mão. Por exemplo, esse sistema de comunicação entre o upload e o video service, daria pra ser feito via webhook, a gente mesmo estanciar, sei lá, tipo, um longo básico ali, só pra salvar o que a gente precisa pra informar e ficar tipo, um worker ali, tipo, escutando essas atualizações. Será que é válido a gente falar, abordar esses passos mais simples que podem trazer menos custo ou a gente, é legal a gente já ir pra outras alternativas e empresas maiores já. Cara, eu diria o seguinte, comunicação desses tipos de coisa, eu nem consideraria o webhook, tá? Você quer garantir a resiliência, a fila, e eu nem caria muito nessa pegada, tá? Agora, trabalhar com abordagens mais simples, eu acho que sempre vale a pena. Não sei se vocês perceberam, mas eu botei a fila aqui por último. Entendeu? Por quê? Eu tentei fazer tudo da forma mais simples e daí a coisa vai pegando. Eu vou dar um exemplo aqui pra vocês. Uma pergunta que com certeza eu faria. Esse video service, por que você está usando banco de dados relacional com ele? Alguém consegue me responder? Eu acho. Não só um relacional, mas também um não relacional, um no-cycle ali para algumas informações. O que precisa ser relacional do vídeo, que é o URL do vídeo, o ID do vídeo, que são coisas que se relacionam realmente, faz sentido um relacional. Agora, metadados, por exemplo, eu não sei o que eu vou trazer de metadados. Não tenho os detalhes. Alguns vídeos eu vou ter cinco legendas, outros eu vou ter três legendas, vou ter dois áudios, cinco áudios, dez áudios. Então, isso eu colocaria num no-cycle. Legal. Vou dar uma segunda dica pra você, quem que falou mesmo? como que é o nome? é que eu perco o zoom Marcelo uma dica que eu dou, caras toda vez pra você não encher de banco de dados relacional que nem a gente colocou aqui a gente pode trabalhar com as seguintes estratégias qual que é a grande sacada forte que um banco de dados relacional tem? ESG. ESG. Basicamente, integridade muito forte. Óbvio, o Mongo tem ESG, também tem um monte de bancos de dados, também conseguem trabalhar. Mas, o grande diferencial do banco de dados relacional é principalmente quando você vai rodar muita transação vocês acham que a gente vai rodar muita transação aqui? é um banco muito mais pra leitura, não é? cara, eu vou dar um exemplo aqui pra vocês, um banco de dados vamos dizer que a gente está falando de AWS um banco de dados que tranquilamente eu conseguiria rodar aqui, tá? Eu conseguiria rodar, por exemplo, um DynamoDB. Mas aí a coisa já mudou de figura. Falei que vai ser um Dynamo, vai ter que explicar o que é o Dynamo. Entendeu? Wesley, por que você usaria o DynamoDB? Bom, o DynamoDB, nesse caso, ele é um banco de dados no padrão NoSQL, de coluna larga. Nesse caso aqui, como eu preciso ter apenas os dados do vídeo, eu posso criar uma tabela do Dynamo e usar como a chave primária o VideoID. E daí, como ainda o Dynamo trabalha com esquemas de partições, cada Video ID ele vai ficar em partições totalmente separadas, digo, distribuídas de forma homogênea, sem ter problemas de partições quentes. Se eu precisar fazer algum outro filtro, eu consigo utilizar uma Sort Key ou uma Local Key ou uma uma local key ou uma GSI, né, que é uma global key, caso eu precise fazer mas nesse caso aqui, um Dynamo ia ajudar pra caramba a minha vida, não precisava de dado relacional não preciso colocar transação ele escala horizontalmente os dados que eu preciso são totalmente colunares, então o DynamoDB serviria muito bem aqui para mim nesse caso. Sacou? Então, nesse caso aqui, um DynamoDB, um Cassandra, que é um concorrente direto do DynamoDB, conseguiria trabalhar. Mas no momento que eu falar esse Dynamo, o cara vai perguntar, como é que funciona o Dynamo? Ah, o Dynamo é um banco de dados distribuído, NoSQL, ele trabalha no formato de anéis, né? Todo mundo manja como é que o Dynamo funciona? Ele tem anéis, que são os vários caras aqui, e daí cada anel tem um número, sei lá, 20, 30, 40, aí toda vez que eu mando gravar um novo dado, o que vai acontecer aqui para mim? Eu vou gerar um hash desse dado e vou falar, se esse hash estiver entre 1, se ele estiver entre 20 e 30, eu vou guardar esse dado aqui, se esse cara tiver entre 30 e 40, eu vou guardar esse dado aqui se tiver 40 e 50, eu vou guardar esse cara aqui, e ele consegue replicar essas informações, aí ele tem separação por tabelas, separações por índices, mas ele não é um cara muito bom, por exemplo, pra fazer consultas totalmente malucas, por exemplo, para fazer consultas totalmente malucas. Então, se eu preciso fazer um monte de consultas malucas, aqui nesse caso, eu posso usar o meu banco de dados de busca. Ah, o DRM Service. Cara, que talvez possa ser realmente um banco de dados relacional para eu concluir uma transação e dizer que quando a licença já foi expedida, pode ser também. Poderia ser um MongoDB nesse caso? Também poderia. O lance de banco de dados, o grande problema de banco de dados é que 80% dos problemas vocês conseguem resolver com os mesmos bancos. Mas daí a gente cai naquela situação. Se eu boto banco de dados relacional para tudo, aí já está mostrando que eu só sei mexer com banco de dados relacional. tudo, aí já está mostrando que eu só sei mexer com banco de dados relacional. Entendeu? Então, a grande sacada aqui no meio dessa história é você pode dar alternativas. Aqui, a gente está trabalhando com banco de dados relacional, a gente está trabalhando com banco de dados em memória, a gente está trabalhando com DynamoDB, que vai me ajudar para caramba. Eu tenho as minhas colunas com todos os dados, lat que vai me ajudar pra caramba eu tenho minhas colunas com todos os dados latência super baixa dependendo da situação olha só que interessante dependendo da situação ao invés de eu trabalhar com o cache eu posso trabalhar com uma parada que chama quem já usou o Dex? que é pra uma aceleração, que é como se fosse um cache no próprio DynamoDB então, a gente começa a explorar um monte de outras opções no meio dessa história. E aí, o nível de perguntas pode começar a engrossar. Por exemplo, eu falei aqui de pipeline de serviço. Pronto, falei desse cara, entre aspas, vou ter que explicar. Aí, por exemplo, ah, eu tenho um pipeline pra processamento dos vídeos. Daí o cara pode começar a perguntar como é que funciona um vídeo. Ou, como é que funciona o encoding desse vídeo? Qual que é um processo recomendado pra eu fazer isso? Aí eu posso chegar e falar assim, olha, existe uma parada que chama DAG. Quem já ou chegar e falar assim, olha, existe uma parada que chama DAG. Quem já ouviu falar disso? DAG. Airflow da vida. Tem gente esperta aí, ó. Então, como que é? Directed a cyclic graph, né? Basicamente, é um gráfico direcionado. Então, ele consegue garantir que você nunca vai ter ciclos de processamento. Como a tarefa é feita, ela já termina para sempre. Então, nesse caso, o que eu posso fazer aqui no meu caso do vídeo? Eu tenho o upload do vídeo. o que eu posso fazer aqui no meu caso do vídeo eu tenho o upload do vídeo do vídeo depois do upload eu posso dividir o vídeo em segmentos mas na hora que eu vou dividir o vídeo em segmento eu posso ter aqui por exemplo uma setinha onde eu vou fazer o transcoding eu posso ter uma outra setinha aqui que eu vou fazer o processamento do áudio. E eu vou ter uma outra setinha que eu posso aqui gerar a transcrição. E essas tarefas elas podem rodar todas em paralelo e depois todas essas podem apontar pra eu criar o arquivo de manifesto com todas as informações do vídeo com todas as informações dos vídeos que eu acabo tendo, então já é uma outra abordagem que ele vai trabalhar, e daí o cara vai perguntar poxa, então quais ferramentas que você tem pra isso? Aí teve gente que falou o workflow. Existe uma ferramenta que chama temporal. A outra ferramenta que dá pra trabalhar com isso, a AWS Step Functions, que você consegue fazer um workflow, você consegue fazer o upload, ver o que que falhou e repetir, fazer os processos trabalharem. O que que outra pergunta mais chata que alguém poderia fazer aí, galera? Distribuição de regiões ali na parte do API Gateway. Poderia ter um similar ao CDN na frente do API Gateway. Ou isso já acontece automático? Cara, isso já meio que acontece automático, porque basicamente o que acontece? Você pode rodar em múltiplas regiões e você pode resolver isso por DNS, por diversas formas. Agora, em contexto de vídeo, sabe uma coisa que seria uma... Eu não digo que seria uma pegadinha, mas, por exemplo, imagina que você chegou e fez tudo isso, eu vou falar assim, cara, imagina agora que eu tô subindo um vídeo de 10 gigas e eu tive um probleminha na minha rede e eu vou ter que subir o vídeo novamente. Como é que eu consigo continuar de onde que eu parei? Entendi. A minha pergunta seria o usuário acessando o Search Service, por exemplo. Acessando o catálogo. Seria a outra parte, mundialmente. Isso ele ficaria não, não, você pode duplicar, replicar essas estruturas por regiões, entendeu? e daí quando você bate por DNS, você cai na região que vai resolver aquele tipo de problema sacou? só que separaria por DNS é, na realidade o que acontece é o seguinte esse search engine, ele pode ser multiregião. Então, esse próprio banco de dados de search não vai ser um único banco de dados, ele é replicado também entre as regiões. Então, na hora que você está batendo determinado uma região, ele vai responder com a infraestrutura daquela região. É como se fosse mais ou menos assim, tá? A grosso modo, é como se fosse mais ou menos assim, tá? A grosso modo, é como se eu tivesse isso aqui copiado e colado pra cada região. Os bancos de dados sincronizados, os microserviços, os pipelines, tudo por região. É um copia e cola. É como se a gente tivesse essa infraestrutura pra todas as regiões. Tá? Na maioria desses sistemas que são de larga escala, eles são, entre aspas, cópias e colas replicados em tudo quanto é região. E os bancos de dados acontecem a mesma coisa. Os dados dos bancos vão sendo refletidos em tudo quanto é região também. E, novamente, cada vez que replica uma região, a conta aumenta pra caramba, né? Hoje em dia você pode escolher zonas de disponibilidades, que são uma região que tem data centers com 100km de distância aí pelo menos, fisicamente. Mas quando a gente vai de região, aí já vai pra um outro escopo e daí você tem multiregião, multizona de disponibilidade. Então seus dados são replicados para caramba, a conta vai vir alta, mas tem situações que não tem muito para onde correr. Eu não posso pedir para todo mundo do Brasil e todo mundo da Europa bater sempre nos Estados Unidos para acessar a Netflix. Então essas estruturas aqui normalmente elas são bem copy and paste mesmo. essas estruturas aqui normalmente elas são bem copy and paste mesmo, tá? Essa daí também vai para os bancos aí, ó como é que vai replicar em zonas da invasão de divisa Cara, meu amigo, mas o DURC existe mesmo, cara, porque cada continente, a Europa tem a lei de proteção de dados dela Exatamente isso, a LGPD Aí a coisa vai o buraco é bem baixo as coisas são bem mais complexas do que esses desenhos mas dá pra perceber a quantidade de coisas que a gente acaba ficando trabalhando aqui nesses desenhos, explorando pra gente fechar galera quem consegue trazer uma solução para mim para a gente fazer com que o upload continue de onde ele parou? Fazer o upload em VH? Desenvolver um cliente, fornecer um cliente. Eu diria que é um cache de array de bytes que esse cara vai ter lá de stream. Eu não sei a ferramenta que pode fazer isso. Talvez com file. Eu teria um banco local no dispositivo do cliente. Eu quebraria o arquivo no dispositivo do cliente e criaria o que já enviou ou não enviou em um banco local no dispositivo. Seria a minha ideia também. Criar um cliente para subir os arquivos. Aí faz multippart, né? Um SQLite local. Não, vamos imaginar o seguinte, galera. Eu estou no meu browser, eu vou fazer um upload de um arquivo de 10 GB. Minha internet caiu, quando ela voltar eu quero que ela pare de onde ele parou. Eu não estou desenvolvendo nada, estou fazendo pelo meu browser. Eu não sei se atende Mas o S3 ele tem a opção do multiparte Com resumo né Eu não sei se nesse caso Entraria Caberia né Perdeu a conexão com a internet Perdeu a conexão Cinco minutos depois eu tento a mesma coisa E ele continua de onde eu parei Acho que eu faria usaria um local storage no browser colocaria esse arquivo num cache do próprio browser, quebrado em vários chunks 10 gigas 10 gigas ou a gente pode tentar quebrar um chunk por cada vez então eu começo eu crio um chunk, mando aí eu tenho que ter um regist, mando, aí eu tenho que ter um registro de quantos chunks eu já criei, criei o próximo chunk, mando, e assim... Mas quando eu voltar, como que você sabe quais chunks foram realmente recebidos? Como que você garante que o chunk que você estava local foi recebido lá no server? Ah, imagina que eu tenho um arquivo de 10 gigas, então vou fazer 100 chunks de 100 megas cada. A hora que eu criar o primeiro chunk no browser com 100 megas, eu vou deixar ele salvo no meu browser, vou criar um local storage ali pra saber que eu criei aquele chunk, e mando pro meu servidor, ó, vou te mandar 100 chunks de 100 gigas, esse é o primeiro. Aí, se em algum momento quebrar, o servidor sabe, ó, eu já recebi os cinco primeiros chunks, manda a partir do sexto. Ou, mandei, recebi o... Como que o servidor fala que ele recebeu os cinco chunks? Teria que persistir em algum lugar, né? Essa informação, talvez um snapshot algum do tipo. Teria que fazer um checksum desses dados recebidos E armazenar Num redis Depois bater lá se esse cara tá Refazendo O upload, né Cara, é uma boa Cara, eu imagino que seria Alguma coisa desse tipo Eu acho que todo mundo concorda com os chunks, certo? Acho que tá bem claro com todo mundo, né? Então a gente tem, divide por chunks, sei lá, por exemplo, de 10 megas. Ok? Mas eu acho que o segredo aqui nesse caso é o seguinte. Depois que eu tenho os chunks, eu gero um hash de cada chunk. Certo? Aí o que eu faço? Uma vez que eu tenho o hash de cada chunk aqui para mim, eu vou fazer o upload. Eu vou fazer o upload dos hashes, ou seja, o metadados Desse metadados Do meu upload Basicamente o que eu vou ter aqui pra mim Tipo Chunk 1 Aqui era pra ser um hash, tá? 1, tipo Uploaded Chunk 2 Not uploaded Resumindo basicamente o torrent aí, né? Not uploaded. A gente tá resumindo basicamente o torrent aí, né? É que o torrent é distribuído, né? O grande ponto aqui é que... Mas o mapeamento dele, né? A questão dos chunks, tudo, é o mesmo princípio, né? Ah, sim, com certeza. Porque o lance é o seguinte. Eu subo os chunks no server. Aí, o que acontece? Quando o meu client fizer o upload, quando eu faço o upload e termino aquele pedaço, eu mudo o status do meu chunk. Agora, como que eu consigo mudar o status? O Marcelo é o cara porque eu sei que ele manja de S3 fala aí Marcelo, você manja, você sabe essa tem várias opções a gente pode mexer com tag, com o próprio metadado do S3, o multipart o encoding dentro do S3 cara, sabe o que a gente pode fazer? cada vez que subir o chunk com aquele metadado, o que eu faço? Eu gero um evento que eu notifico uma lambda e essa minha lambda faz o quê? Atualiza o banco de dados falando que ele já subiu. Então, para cada chunk que eu subo, automaticamente o S3 notifica minha lambda, minha lambda dá baixa aqui no meu banco de dados. Quando todo o meu banco de dados estiver ok, eu sei que o upload está totalmente completo. Se não tiver, eu tentar novamente ir do browser, eu vou ter os mesmos fingerprints, porque os hashes são dos mesmos tamanhos, e o conteúdo, eu continuo exatamente de onde eu parei. Pode ser uma solução, né? Eu consigo afirmar que os chunks gerados vão ser sempre os mesmos? consigo, porque a gente está falando do mesmo arquivo, do mesmo byte com o mesmo checksum se eu for separar exatamente no mesmo formato sempre vai ser a mesma coisa entendi, ele não tem uma parte aleatória embutida no meio no final das contas um vídeo é um array de bytes se eu falo quero pegar 10 megas desse array de bytes eu posso pegar quantas vezes eu quiser eu vou sempre ter os mesmos 10 megas e em tese o meu hash vai ter que ser sempre o mesmo a única diferença aqui é que a gente está primeiro pegando os hashes desses caras e gravando no banco de dados gravou no banco de dados. Gravou no banco de dados? Maravilha. Agora eu começo a subir. Cada vez que subiu, o S3 fala, opa, esse aqui está pronto. Minha Lambda vai lá assim, ah, beleza, olha, esse cara aqui está pronto, então pode dar baixa nesse cara, até os dados forem inteiros completos. É uma solução, não estou dizendo que é a única, tá? Não estou dizendo que é a única. Ele pode receber o byte lá da frente antes do byte do início. Tanto faz, exatamente. Tanto faz. Se ele tiver todos, o arquivo está íntegro. A minha dúvida seria só manter um arquivo muito grande no cache do browser. Entendeu? No storage. É que vai estar quebrado. E cada vez que subir, você vai arran, né, essa que é a grande sacada o maior problema é você tentar subir o arquivo de uma vez, aí assim, é basicamente impossível de rolar mas o fato é a gente tem que quebrar em vários inclusive teve uma imersão que a gente fez no final do ano que a gente fez exatamente isso, ano que a gente fez exatamente isso tinha que fazer uploads grandes de arquivos e o Luiz Carlos ele mandava pro meu programa em Go os chunks aí eu pegava os chunks e grudava esses chunks formando um único arquivo de novo e aí que eu fazia a conversão de vídeo acho que era bem isso mesmo foi bem isso mesmo então você vai dar a respeito do browser você tá subindo um arquivo você tem você sabe me informar quanto ele seria Lisa para mandar porque ele vai ser realizar esse arquivo do lado e mandar para o outro serializando ele e ele não vai mandar de uma vez, ele vai passar por on-demand lá ele vai passar a demanda dos bytes cada passagem desses bytes aí você tem que pegar um outro protocolo que o HTTP não vai deixar você fazer isso deixa, normalmente a única diferença é que no final das contas na hora que você pega o vídeo você mapeia aqueles caras e você carrega na memória naquele momento no seu client somente aquele pedaço que você quer enviar, pra você não ter que carregar tudo na memória. Você faz isso com um estudo, no final das contas. Você vai lendo eles por pedaço. Aí você não precisa ler tudo, porque senão você vai enfiar 10 gigas de memória no seu browser e é impossível de você aguentar. Então você vai ter que ir quebrando, mas o ponto é, quando você quebra esses pedaços, você tem o início e o final do array. Você gera o checksum daqueles pedaços. Aí você sobe no servidor, e aí você vai subindo, obviamente, com vários passos, porque se o arquivo é muito grande, cara, é realmente impossível. É, é porque eu imaginei quebrar já direto no browser, sabe? Por exemplo, assim, se eu fosse subir, eu queria saber quanto o browser faz para serializar se tinha como eu pegar a chegada, mas quando você faz via HTTP, ele é sincron, ele vai montar toda a estrutura do upload ali, jogar na memória do browser e depois trafegar aquilo ali tudo. Aí ele vai ficar lá do outro lado, você tem que interceptar ele antes do seu HTTP, do seu qualquer protocolo que você tiver lá. Cara, não, o HTTP, ele transfere dados. O vídeo é simplesmente um array de bytes. Então você está mandando um array de bytes de HTTP. Então, por isso você tem que quebrar, porque se você botar tudo, na realidade o que vai acontecer é que é muita informação e pode demorar muito tempo. E aí se a conexão do servidor ou do client cair, você tem que começar tudo do zero. Então por isso que mandar os arquivos menores você tem menos chance dessa conexão cair, mas mesmo assim cai. E por isso que se você conseguir anotar os pedaços dos vídeos pra garantir que do outro lado você tem ele inteiro, acaba tendo mais segurança que você receber o vídeo todo. E no final das contas, você pode ter um check-champ, um fingerprint, né, no final das contas, do vídeo inteiro na sua máquina, do client, e o mesmo fingerprint no vídeo que grudou os pedaços lá no server e vê se esses caras batem. Eles têm que ser exatamente os mesmos na hora de você grudar os bytes de volta. Mas eu acho que é mais ou menos essa pegada. Cara, dá para explorar coisa para caramba, né? Dá para ficar aqui horas na CDN, dá para ficar horas no Dynamo, horas no Redis, horas no processo de upload, horas no Elasticsearch, horas na DRM, mas o que eu acho que é o ponto mais importante é a gente conseguir ter a seguinte manha, faça o System Design da forma mais simples e vá sempre comunicando, olha, estou fazendo da forma mais simples e vá sempre comunicando, olha, eu estou fazendo da forma mais simples, não estou pensando nesse momento na resiliência. Agora eu estou pensando, eu coloquei uma fila, tá? O banco de dados aqui, eu estou colocando um relacional, mas eu acredito que dá para a gente mudar isso para o Dynamo. Ah, eu acredito que aqui dá para utilizar o Elastic, aqui pode usar o Redis, aqui pode usar o Redis, aqui pode usar o Mongo. Então, esses tipos de coisas ajudam bastante. A dica que eu dou aqui para vocês em relação ao que estudar, em relação a System Design e Forma em geral, é o seguinte. Anotem. Um, ter um conhecimento bacana de S3. E eu estou falando S3 especificamente porque é um dos serviços mais conhecidos e os outros cloud providers usam o mesmo drive para conseguir se comunicar mas por exemplo a URL pré-assinada que o Marcelo colocou, vira o jogo só de saber que esse recurso existe, muda completamente o jogo porque sem essa URL pré-assinada, eu teria que jogar o arquivo por aqui e fazer um proxy. Aí, acabaria com a minha vida aqui. Então, só esse sistema já iria colocar. Então, se você não sabe que existe a pré-assinada, você iria por essa linha aqui. E se você for por essa linha, o seu serviço já não iria aguentar. Então, provavelmente... Tem que contar que o próprio API Gateway, se for usar o AWS API Gateway, ele tem um limite ali. Tem um limite também, exatamente isso. 10 MB de tráfego, né? Exatamente isso. Então, ó. Aí, S3 também, olha, tem os eventos que eles conseguem gerar. Então, isso são coisas importantes se o evento gerou, ele vai comunicar pra algum outro ponto que eu posso receber então pode ser uma outra coisa interessante estudar um pouco mais como funciona uma Lambda Function outra coisa importante pra estudar, galera filas, tá? Comunicação entre sistemas, resiliência outra coisa pra estudar, definitivamente banco de dados você não precisa ser um mestre você não precisa entender sistemas, resiliência. Outra coisa pra estudar, definitivamente, banco de dados. Você não precisa ser um mestre, você não precisa entender a fundo sei lá, o DynamoDB. Mas sim, você precisa entender as categorias dos bancos de dados. Então eu tenho o DynamoDB, eu tenho o Cassandra, a ideia deles é exatamente a mesma. Tá? Ah, banco de dados e memória. Cara, Redis já é mais do que o suficiente se você entender razoavelmente bem como ele funciona, ele é mais que o suficiente a gente vai remarcar a aula com o Ricardo Ferreira que trabalha na Redis ele vai dar uma aula de Redis bem bacana pra gente assim que eu conseguir confirmar a data com ele eu retorno aí pra vocês tá? Bancos de dados de busca. Também deem uma pesquisada e deem uma boa olhada como esses caras funcionam. Também API Gateway. São outros pontos importantes para vocês terem conhecimento. E também, sempre ficar ligado que essas pegadinhas acabam acontecendo. Continuar o upload da onde parou tá, isso aí é algo que eu quantos de vocês já tinham pensado nesse tipo de problema? nem todo mundo, fala a verdade é difícil todo mundo ter pensado porque raramente a gente só pensa naquilo que a gente já teve que fazer né, então isso aí é um ponto importante, então já é mais uma coisinha que entrou no repertório de vocês hoje, outra coisa, quem aqui já tinha ouvido falar no DAG, né pra processamento de qualquer coisa em paralelo, né? Ou seja, o processo acíclico de grafos, basicamente. Tá? Então, isso aí já também é mais uma coisa que acaba entrando no repertório também de vocês hoje. Agora, se alguém falar de DAG pra você, Directed Acrylic Graph, basicamente você fala assim, opa, eu consigo paralelizar tarefas e eu sempre vou tendo que ir seguindo pra frente. Então, eu consigo trabalhar, por exemplo, numa Netflix da vida, provavelmente, esse cara, ele consegue gerenciar o seguinte, olha, eu recebi um vídeo, esse vídeo tem que fazer a parte de transcoding. Ele já consegue atribuir qual é o worker que vai processar aquele pedaço. Eu consigo escolher qual é o worker que vai processar aquela outra carga. Qual é o worker que ele vai processar aquela carga. Quando todos os workers terminarem, aí ele gera um resultado final. E tudo isso roda de forma paralela para não ficar um único serviço fazendo. Todos esses controles aí ajudam para caramba. Então, eu recomendo também que vocês deem uma olhada sobre, por exemplo, AWS, Step Functions. Vocês podem olhar no Airflow. Vocês podem olhar no Temporal também. São três caras aqui que conseguem resolver esse problema referente à DAG. referente a a DAG tá, então são mais coisas aí que acabam aparecendo e que em algum momento, quando alguém falar numa mesa de bar ou numa entrevista você já não vai ficar ali tão perdido, né, de como trabalhar e a graça que eu acho de System Design é que cada vez que você faz um, você acaba aprendendo coisas de um domínio que você não está acostumado. Então, talvez quem nunca tenha trabalhado com vídeo ou algo de direito autorais nunca tinha ouvido falar em DRM. Ou alguém nunca tinha ouvido falar em CDN. Ou no próprio pipeline com Step Functions. Ou URL pré-assinadas. Então, é o tempo, necessidade, e eu acho legal essas aulas, porque elas te forçam a pensar em cenários que você não está acostumado a ir a trabalhar. Fechou, galera? Então, pessoal, a gente vai editar essa aula da melhor forma possível e a gente vai disponibilizar na plataforma para que vocês possam assistir. Espero que vocês tenham gostado e tenham aprendido coisas diferentes aqui. E assim, não tem muito certo e errado com o System Design. Eu acho que a principal realidade é que quanto mais repertório você tiver, mais opções você consegue dar para ser mais assertivo para resolver problemas específicos. Mas, independente do seu repertório, a minha mensagem final que eu queria trazer para vocês de System Design é isso. No final do dia, tudo começa por aqui. Você tem que mapear as core features, definir a entidade e implementar os endpoints. Se os endpoints que você prometeu estão sendo cumpridos no System Design, você terminou o System Design. Não importa se você botou banco de dados relacional para tudo, não trabalhou com fila, não usou API Gateway, mas você conseguiu fazer o sistema funcionar. Após isso, você vai tentar obviamente fazer que sejam cumpridos os requisitos não funcionais. E aí você vai acabar caindo com fila, vai acabar caindo com CDN, vai acabar caindo com API Gateway. Mas, no pior das hipóteses, garanta que você implementou os seus endpoints. E nem sempre vão ser endpoints. Às vezes são comandos. Às vezes você não precisa ter endpoints REST, por exemplo. Às vezes você vai executar um comando, você está fazendo um client, um sistema local. Mas a ideia é exatamente a mesma. Fechou? Pessoal, então a gente vai editar esses vídeos. Eu vou organizar esse Scully Draw pra conseguir passar pra todos vocês, aí vocês podem olhar com calma, brincar, revisar todo esse documento e a gente vai se falando. Fechou? Galera, é isso aí. Muito boa noite aí pra todo mundo, espero que vocês tenham curtido a aula. Quem tá chegando agora no MBA e pode ter ficado perdido com alguma coisa saiba que em algum momento você vai bater no nossa aula de System Design algumas coisas vão ficar mais claras pra vocês mas de uma forma geral eu acho que todo mundo conseguiu pelo menos deve ter pegado a ideia principal do que a gente tenha trazido aqui hoje fechou?