Entrevista para Dev Senior na Europa ao vivo

tá começou eh pessoal hoje eu e o Leonardo Vamos fazer uma entrevista de System design eh como a gente como ela é na na vida real a gente já fez Essas entrevistas várias vezes eu principalmente do lado do entrevistado o Leonardo várias vezes do lado do entrevistador Então a gente vai estar apresentando aqui como isso funciona e vamos fazer uma espécie de mock interview né Eu sou entrevistado e Leonardo é o entrevistador Léo se tu quiser fazer uma apresentação aí de quem tu é fazer a todo mundo eu sou Leonardo Menezes eu sou engenheiro Manager

e trabalho hoje na Europa eh hoje vou est fazendo uma entrevista de System design com Augusto e passando um pouco do que a gente passa nos processos de recrutamento aqui na Europa também então vamos lá bora começar o que que a gente tem para hoje lá então Augusto a gente vai desenvolver um serviço de streaming de vídeo a responsabilidade desse serviço vai ser primeiro fazer em gestão desse desses vídeos dentro de um banco de dados você não precisa se preocupar com a parte de streaming de vídeo em si Então vai ter uma biblioteca que vai

gerar todos os chunks que vai fazer toda a responsabilidade de Realmente streamar isso pro browser dos clientes eh vai ser Primeiramente só o Web também então vai ser um serviço como se fosse o YouTube web por exemplo os e você vai ter que retornar esses chuns que essa biblioteca vai oferecer pros clientes os únicos requisitos vão ser eh cada usuário só vai poder ter no máximo quatro devices streamando ao mesmo tempo e os vídeos vão conter alguns metadados que a gente pode usar no futuro então por exemplo cada vídeo vai ter a origem o país

origem deles vai ter eh qual foi a empresa que publicou eles e talvez no futuro a gente tem algumas regras de por exemplo dependendo do seu plano você pode ou não você tem acesso ou não a assistir aquele tá beleza vamos vamos por pass assim eu não sei nada de de streaming de vídeos acho que isso não vai afetar muito o exercício e tá a gente vai fazer então System design de um streaming web com cada usário para ser quatro devices a gente vai ter os metadados que mais você falou que é importante quatro devices

no máximo vai ter metadados que vão ser filtrados no futuro e é só isso e que nem você falou o a parte do streaming não é o que a gente não tá testando aqui algoritmo de Então só imagina que você vai receber um vídeo você vai ter que armazenar o o vídeo de origem só que vai ter uma biblioteca que vai separar aquele vídeo em Chun que você pode entender como se fosse um um arquivo binário e são esses chunks que você vai ficar oferecendo pros usuários a cada 10 segundos por exemplo sim tá esse

então eu vou receber esses vídeos eu vou armazenar eles de alguma forma e aí do meu do meu banco de dados eu puxo e envio pros usuários né Mais ou menos essa ideia saber chunks e armazenar bom é para quem também não faz menor ideia de como é que é uma entrevista de System design a gente quer desenhar aqui não não tem a ver com o código per se é mais uma uma visão Geral de como que a gente vai organizar os servidores e bancos de dados e que tipos de hardware firmware a gente vai

usar para fazer com que o que a gente precisa chegue de fato no usuário então geralmente como eu começo aqui e eu começo desenhando o o nosso usuário que né é o é o ponto ponto Central aqui do da coisa é tá a gente tem o nosso usuário nosso usuário vai acessar isso aqui essa a nossa aplicação num a gente pode imaginar que é um celular ou qualquer coisa do tipo e ele vai poder estar acessando em quatro né Eu não sei como é que isso vai afetar a gente mas a gente vai descobrir no

no futuro é ah um detalhe sobre isso vai ser responsabilidade desse serviço garantir que são no máximo quatro então é como se fosse uma parte do produto tipo Netflix pode assistir em quatro lugares diferente sim sim sim aham Com certeza Ah muito bem a gente tem o nosso celular no nosso celular a gente vai ter um front Change eu acho que a gente não precisa entrar em muitos detalhes sobre sobre isso e esse front Change o básico do básico de um de um System design é que a gente vai ter um front ch um servidor

aqui e um banco de dados eh isso aqui seria o né é o MVP o mínimo produto viável só que claro que isso aqui não não vai funcionar e não não vai não vai escalar bem não vai ser razoável eh pr pra gente ter alguma alguma certa eh escalabilidade é quase sempre recomendado que a gente tem um load balancer aqui na frente então acho que a gente já pode colocar essa parte aqui para receber os requests dos usuários e o load balancer pode Balancear isso para um ou mais servidores né a gente pode imaginar aqui

que a gente tem dois servidores eu acho que não bom a gente vai descobrindo como que a gente vai fazer as coisas temos o l balancer temos dois servidores a questão é eu vou eu preciso fazer o como que a gente vai receber esses vídeos como é que eles vão e a gente tem você vai puxar isso de algum lugar a gente tem algum serviço para para receber os vídeos eu tô tentando imaginar como é que eu vou colocar esse recebimento dos vídeos no no nosso sistema design aqui imagina que vai ter um serviço interno

que vai fazer um request ou como você desejar receber o eles e aí esse sistema vai mandar esses vídeos novos ingeridos para você tá então vou imaginar que a gente tem aqui o outro serviço o serviço de de vídeo e a gente vai ter um não sei se é muito importante o que que isso daqui vai ser mas o nosso é processing service nosso serviço de processamento você acha que tá zá isso acho que faz sentido então separar as responsabilidades entre engerir E servir os clientes é isso isso ele vai é a ideia que eu

quero aqui é é puxar os nossos vídeos e jogar os vídeos em né a gente tem que fazer os chunks né a responsabilidade desse serviço aqui do processing é transformar o vídeo em chunks e armazenar no nosso banco de dados que a gente vai precisar decidir qual vai ser Inclusive a gente tem aqui o nosso DB né eu propositalmente não não especifiquei qual que qual que é o banco de dados porque eu tô pensando sobre Ah cara Geralmente eu quase sempre uso um um postgress para para quase tudo eu acho que é uma solução razoável

mas eu não sei se para vídeo vai ser interessante porque geralmente você armazena um vídeo numa numa blob Store você não vai armazenar um um vídeo inteiro via postgres e servir não faz sentido armazenar os binários dessa dessa maneira eh tradicionalmente eu vejo vídeos sendo armazenado em S3 então talvez se a gente armazenar os chunks no no S3 ao invés de pensar nisso aqui no com banco de dados eu acho que por enquanto vou imaginar que é um S3 me parece me parece razoável eh e eu só não sei como é que a gente vai

bom depois eu penso como é que a gente faria para armazenar as chaves e saber qual vídeo é o que especificamente eh muito bem o nosso usuário vai eh solicitar um vídeo aqui no nosso load balancer o load balancer vai decidir para qual server mandar esse esse request né Imagino que a gente tenha um eh dois servers e o nosso server vai puxar a informação aqui do nosso S3 e retornar eh infelizmente isso aqui não não é um banco de dados né isso aqui é um S3 a gente também precisa de algo para autenticar o

nosso usuário a gente precisa de alguma né porque a gente não vai ter toda a informação Ness TR isso não faz sentido é o usuário vai ter mais informações sobre qual o plano que ele paga ou enfim que exatamente que ele tem acesso em algum lugar a gente precisa de um banco de dados mais tradicional também eh na minha visão eu usaria o posters eu quase sempre uso SQL para para resolver esse tipo de problema mais corriqueiro porque é o padrão eu acho eu acho que é razoavelmente fácil você não fazer tipo você ter um

um SQL básico para resolver esse tipo de cois coisa eh o nosso load balancer também precisa est conectado em algum tipo de de serviço de autenticação a gente dá para fazer isso pelo server também mas eu acho que eu acho que a autenticação é porque você pode jogar isso aqui num Geralmente as soluções são algo como um kickl ou ou off algo nesse sentido e você vai fazer isso geralmente antes do request chegar no servidor para você já conseguir e negar esse request a nível de load balancer né então perfeitamente correto a empresa já tem

um serviço disso você pode manter no desenho para imaginar como o seu sistema vai interagir com as informações do usuário mas a empresa já vai te fornecer isso não precisa se preocupar muito com a autenticação tá tranquilo Eh que que você acha que é importante eu pensar agora eu tô não sei para onde exatamente levar isso então o eu recomendaria a gente tentar seguir o fluxo então Eh o usuário faz a requisição o que ele precisa receber de volta Quais checks que você quer fazer ISO Ah o que que ele precisa receber de volta ele

não ele vai ser aqui no L balancer é ou Deni vai ser permitido vai passar aqui pro servidor ele vai receber os chunks a gente tem que em algum momento é resolver isso aquii também né esses quatro devices e para resolver isso de quatro devices a gente precisa de algo para armazenar as sessões de cada usuário isso pode est também conectado no nosso serviço de de autenticação aqui e porque cada request vai ter que dizer se o usuário tá autenticado ou não ele já vai ter alguma forma de de sessão mas pra gente fazer isso

de uma forma razoável que seja rápida Eu acho que a gente podia ter um redes por exemplo e em que a gente busca rapidamente por kys do né cada usuário tem um ID a gente vai buscar pelo id do usuário nosso Reds e bater ali para ver o número de de sessões que ele vai ter então ele só pode ter quatro ativas Eu acho que isso pode resolver o nosso problema de de quatro devices que que você acha Eu acho que a ideia de ter um armazenamento rápido como RZ para para isso é boa a

única coisa o único problem que é um requisito de negócio que esses usuários possam conseguir logar com mais de quatro devices então por exemplo a pessoa pode ter mais de quatro devices explorando e com sessões ativas em dispositivos diferentes olhando catálogo aí a única coisa que ela não pode fazer é consumir conteúdo Então ela não pode estar consumindo o mesmo conteúdo ou conteúdos diferentes e em mais de quatro Dev ao mesmo tempo Entendi então a gente não a gente não vai conseguir negar ou permitir os os requests baseado nisso a gente vai precisar pensar numa

solução um pouquinho diferente Eu ainda acho que a gente consegue usar o redes para ter as sessões e bom você consegue permitir que que o usuário tenha enfim quantas sessões você quiser no redes e nessa sessão Você pode ter uma Flag de se ela tá consumindo ou não o o vídeo no momento esse esse update das sessões pode ser feito no nosso servidor aqui a gente não definiu exatamente o que que é o servidor né não sei se é tão importante assim mas a gente pode imaginar que a gente tem AL algumas S2 é uma

duas ou até um cluster ou enfim alguma algum outro formato de de rodar o nosso server você acha que tá razoável isso acho que tá mas uma pergunta que eu tenho em mente é como você vai até definir que o usuário vai tá em devices diferentes e então uma pergunta até quase fundamenta é fundamental Não pode Não precisa estar necessariamente no design Mas como você vai perceber por exemplo que agora eu tô no meu celular e agora eu tô no meu computador por exemplo e quais problemas ou limitações você vê diso eu não sei se

eu sei fazer isso cada cada cada device eu acho que tem alguma informação que você consegue pegar no request para ver se é um device específico não Você não tem um você consegue pegar o Mac ID ou algo nesse sentido você sabe disso você você consegue porém como você não você não controla muito o que acontece também no lado do do cliente então é uma ideia tentar mandar essa informação mas ele pode tentar forjar isso também mas a gente pode começar com isso pro primeiro design tá vamos imaginar então que aqui né aqui a gente

tentou tentou forçar a receber um Mac ID ou algo nesse sentido eh Pois é mas se o cliente realmente quiser eu não sei se tem como a gente impedir que ele por exemplo se ele tem sei lá 10 devices na na mesma casa tentando Puxar esse esse vídeo eu não sei como como evitar isso honestamente sem ser se a gente se ele conseguir forjar né É porque essencialmente ele consegue fingir que é tudo o mesmo device Se tiver tudo saindo pelo mesmo pelo mesmo P né pelo mesmo Gateway ali no na wi-fi dele isso por

isso que eu acho a gente a gente pode conversar um pouco mais sobre essas limitações e Talvez algumas estratégias para tentar prevenir isso e nenhuma delas vai ser perfeita nenhuma delas vai ser a prova de falhas mas eu acho que pro primeiro design a gente usar um identificador Universal do do device supondo que ele não vai tentar forjar é bom suficiente pro primeiro O único problema que eu ainda vejo nisso é o os metadados eu não vejo ainda como a gente vai filtrar pelos metadados hum verdade tá a gente bom isso que eu acho que

quatro div a gente tem uma solução minimamente razoável para isso e streaming tá mais ou menos menos web beleza metadados filtrados não sei e receber chunks e armazenar tá esse filtro de metadados para qual qual que é a a intenção disso a gente vai querer usar isso para algum tipo de de Big Data assim ou coisa nesse sentido a gente vai usar isso PR verificar permissão no futuro então por exemplo a gente pode falar que um usuário por enquanto a gente tá falando só de um um um location só mas por exemplo no futuro talvez

a gente tenha o requisito de usuário americano não dev podia conseguir consumir nenhum conteúdo brasileiro por exemplo entendi entendi e Pois é os nossos chunks estão em um S3 dado dado esse fato que eles estão num S3 bom a gente vai ter um um aqui né um um ID para cada Chunk e eu não sei se tá para armazenar os metadados num num né a gente tá pensando que que a gente vai jogar um vob basicamente né essencialmente um um binário Largo que vai ser o Chunk e vou vamos vamos supor que não tem como

jogar Os metadados no C3 não sei se é verdade ou não e a gente consegue através dessa dessa Kia aqui linkcar isso com com alguma alguma informação a gente pode ter esses metadados armazenado em outro outro banco de dados Meu Deus a gente tá usando 75 bancos de dados né mas enfim a gente precisa de uma alguma solução para armazenar esses metadados se a gente tem uma chave um um um ID do Chunk a gente consegue a gente conseguiria armazenar isso qualquer coisa essencialmente é eu vou dizer aqui um Dynamo eu não pensei muito sobre

isso ainda a fundo a gente pode até discutir qual seria um banco razoável para isso Hum E só que aí que tá né porque nessa nessa eu não gosto muito dessa round Trip aqui de vi buscar o Chunk e vim buscar não me parece tão performático eu acho que tem como existir de repente alguma alguma solução aqui que eu não tô visualizando Você tem alguma ideia de repente que não não requeira esse essas indas e vindas para vários bancos diferentes é eu não me preocuparia muito com com essa parte por enquanto se se você precisar

usar um S3 e ou ou um blob Story e um banco tá tudo bem tá Eu eu acho que assim a gente consegue a gente conseguiria armazenar os metadados num num Dynamo né e eu eu gosto do Dynamo que eu acho que a velocidade dele é razoável e a gente consegue ter uma uma hash Key e uma é qual que é o nome enfim consegue ter dois tipos de Keys diferentes então uma das keys seria essa daqui e eu acho que isso aí Perfumaria razoável isso é bem legal tá E só para nosso assumi nada

sobre a sua solução eu também tô imaginando que o processing service ele vai inserir nos dois é isso Ah é É a gente precisa disso verdade a gente precisa que o processing service também e insira aqui Ah aqui agora falando no processing service né h a gente poderia também entrar um pouco em detalhes em específicos sobre isso daqui como a gente tá lidando com vídeo e a gente pode pode imaginar Que vídeo é algo né bastante Largo que tem vários chunks a gente não não quer perder uma informação ali no no meio a gente precisa

de enfim a gente precisa que o vídeo seja proc se Vita um vídeo de 20 30 GB a gente precisa garantir que esse vídeo vai ser processado de uma forma né é razoável tolerante a falhas Então dentro desse processing service se a gente quisesse entrar em alguns detalhes a gente poderia ter também e filas e Ret kills e enfim diversos Jobs para para garantir garantir que o nosso vídeo vai ser processado de início a fim não sei se quer entrar nesse detalhe enfim PR onde que você que levar esse System design agora não mas isso

é bom para saber saber algumas opções e e e r cases que você tá vendo É legal você falar isso tá eh então primeiro Vamos pensar sobre os próximos passos desse serviço eu acho que ele tá funcionando pro início vamos falar que a gente quer expandir para outros países Então vamos falar e que a gente tá inicialmente no Brasil e agora a gente quer lançar esse mesmo serviço nos Estados Unidos quais seriam as considerações que você faria pra gente poder permitir esses dois lugares diferentes quais seriam as mudanças n ou se você vê alguma mudança

que necessária nesse nesse design e considerações que você faria nessa nessa transição sim eu acabei de me tocar uma coisa eu sei que vídeo é muito entregue via eh CDN eu não sei como que uma CDN funciona eu não sei como é que a gente conseguiria encaixar esse chunking numa numa CDN mas até no sentido de querer expandir isso para vários países é é muito Custoso você tipo ter esse vídeo em um banco de dados vamos supor nos Estados Unidos querem entregar isso ir pra Austrália vai não vai ser legal vai sair bem caro inclusive

então primeiro que a gente precisa ter Sem sombra de dúvidas eh essas coisas aqui eh replicadas eh na verdade a gente precisa ter uma replicação de quase tudo na minha visão se a gente quiser que o nosso serviço performe razoável né com uma com uma latência razoável também se a gente tá expandindo Para muitos países com uma escala Global assim vamos supor 1 milhão de usuários acessando simultaneamente isso que não não vai dar certo a gente não consegue ter só só um banco de dados servindo servindo chunks de vídeos não faz o menor sentido a

gente precisaria que tudo isso aqui tudo isso que a gente fez basicamente fosse uma region Então vamos vamos fazer um um negócio aqui um pouco mais mais High level eh deixa eu pegar isso eu vou copiar eu vou colar eu vou reduzir bastante tá esse sim design não precisa vamos imaginar então que boa parte disso tá dentro de uma region e eu ainda preciso pensar preciso definir o que que vai est onde que vão vão est as coisas né Mas vamos lá temos um usuário que a gente não sabe onde ele tá eh necessariamente né

No No momento que ele faz o o primeiro request PR PR e PR DNS e isso aqui vai resolver para para algum algum IP nosso né E só que a DNS não não sei se ela tem como já direcionar o usuário pra região que a gente quer então por exemplo a gente pode imaginar que boa parte disso aqui tá em US East um e a gente tem só deixa eu definir quais dessas coisas eu quero na dentro da região load balancer Vamos jogar o load balancer fora tá vamos derar isso aqui a gente tem server

servers Reds Reds é Reds é o que a gente tá usando para checar os quatro devices é isso isso seria complicado porque se a gente tiver tiver o usuário nos Estados Unidos e na Austrália a gente precisa que essa informação de quem tá aonde esteja available né esteja disponível em todos os Reds mas tá Depois a gente pensa num uma forma de fazer comunicação dessa disso aí eh eu acho que aqui a gente pode pode imaginar um não precisa ser não sei se faz tanta diferença mas enfim a algo que que resolva a a região

do do usuário porque eu realmente não sei como fazer essa parte como Tipo se eu tô no Brasil como que eu sei qual o endereço do do do meu server né do meu para onde que eu quero enviar esse request Então eu só tô abstraindo isso para um um serviço que vai dizer pro usuário e aonde que da onde que ele quer puxar essa informação né Lógico que ele vai conseguir e Teoricamente burlar isso se ele quiser mas ele já conseguiria com VPN de qualquer forma não sei se tem muito como como evitar eh aqui

no momento que ele já já resolveu a região a a gente pode ter as nossas coisas de novo né a gente pode ter o nosso lo balancer a gente pode ter todo o o resto aqui do do serviço inteiro a nossa existe uma consideração importante para se fazer aqui no postgress que a gente vai precisar ter isso replicado globalmente né a gente precisa que o que o post é a gente precisa que o post seja replicado globalmente eh essa parte você não precisa desenhar muito porque a parte de autenticação vai ser responsabilidade de outra equipe

dentro da empresa mas é legal pensar saber como você tá pensando sobre isso sim e é enfim só para e dizer o que que eu tô pensando eu imagino que a gente tenha em porque eu eu eu acho que que essa parte de o criar o usuário a gente não precisa de performance nisso que o usuário só cria uma vez basicamente então a gente pode ter um post que seja eh WR only e seja replicado globalmente para vários pogs que tenham eh capacidade de Read Ah enfim a gente podia também falar um pouco sobre e

replication ou charging é daria para fazer um charging em algum nível e se não encontrar o usuário numa região tentar buscar em outra mas a gente tá entrando numa complexidade que não acho que não entra nesse não é tópico para hoje ã tá fechou você para que a gente leva isso agora cara gostei bastante da abstração que você fez ali porque pelo que eu lembro que você falou você não tinha certeza se o DNS conseguia fazer essa resolução por de região E aí No pior dos casos você teria um serviço Que resolveria a região e

retornaria acho que isso faz sentido o DNS você consegue fazer baseado no geolocation que nem você tinha imaginado mas eu gostei de saber que você tem esse você consegue ver opções ou seja se o DNS não conseguisse fazer resolução baseada em geolocation você conseguiria resolver isso de outra forma ISO bacana tá eh próximo passo Então vamos falar que a gente que a empresa tá indo muito bem a gente tá streamando muito vídeo e a gente fechou um contrato para streamar um evento muito grande tipo as Olimpíadas por exemplo ou streamar um conteúdo que vai ser

lançado um filme que vai ser lançado pela primeira vez na plataforma você imagina que você exato imagina que você não tem acesso a fazer load testing para para fazer para se preparar para esse evento vai ter 10 20 vezes mais usuário do que você geralmente tem e você precisa tentar fazer algumas estimativas de quais partes você acha que iam virar gargalos quando a gente começasse a escalar Então quais são o gargalo ou os gargalos que você vê nesse sistema que seriam a sua prioridade para se preparar para esse sim eh eu acho que o O

primeiro é é isso daqui o o nosso nossos chunks aqui a gente e Bom na verdade você quase tudo aqui é um gargalo né Eh mas vamos por partes nessa questão aqui dos chunks em como que a gente conseguiria entregar esses chunks né imaginando que a gente não ten não tem a solução da da CDN que é onde eu pensaria em em jogar isso numa numa CDN que eu eu até eu sei que grandes empresas T até cdns próprias então então por exemplo a Netflix ela tem alguma algum tipo de CDN própria e tentar levar

isso para mais perto dos usuários possíveis vai fazer com que o streaming do vídeo perc seja melhor mas imaginando que a gente não tem acesso isso porque realmente não sei como funciona muito bem a gente precisa que isso aqui performe muito muito muito bem a gente não pode ficar fazendo eu acho que se a gente ficar fazendo round Trips pro banco de dados o tempo inteiro Não vai ser tão legal eu acho que a gente precisa de alguma algum tipo de e eu tô tentando pensar numa solução que não seja muito muito nonsense mas assim

se a gente imaginar que um vídeo tem sei lá 40 40 GB Talvez eu consiga deixar isso aqui em em memória dentro do da S2 mesmo então uma uma cche dentro do próprio servidor de alguma forma e para ele realmente não precisar acessar nenhuma outra máquina física para puxar esses dados se a gente imaginar que a gente tem os 40 GB dentro do do eh isso ia ser legal ia ser ia ser um caos para para devops para fazer isso aqui funcionar né mas talvez funcione vamos supondo que a gente não não consiga isso aqui

né que isso que Tecnicamente uma solução muito muito fora da caixinha e não faz tanto sentido não mas eu eu eu gostei da ideia então a gente faria a gente faria um Cash em Memory na aplicação e o que você botaria nesse Cash vamos falar que você tem esse esses 40 GB para para cada uma das máquinas virtuais o que você botaria sim eh bom a gente precisa aqui do dos chunks 3 A gente precisa também dos metadados do do Dynamo e na minha visão é É isso aí você faz o o formato em específico

não não sei direito como a gente faria mas você precisa ter os metadados você precisa ter ter os chunks Mas você botaria de quais shows por exemplo ou como você escolheria qual qual vídeo você tem que botar você botaria do da última requisição E aí você iria começar a expurgar ele conforme eh quando você chegasse no máximo de memória e você precisasse tirar o o jun anteriores ou você faria de algum show específico qual seria essa estratégia de é expurgar conteúdo acho é eu acho que do show específico que a gente tem porque a gente

sabe que a nossa demanda de de 20 vezes o normal vai ser por causa do do lançamento de um show específico Então acho que isso tem que tá sempre em cash não não interessa muito qual que foi a última requisição porque né supondo que a gente tem os nossos 40 GB vai ter simultaneamente as pessoas assistindo e aquele show que lançou só que vai ter um monte de gente assistindo um monte de coisa aleatória no meio do caminho então se a gente ficar trocando essa Cash talvez não faça muito sentido a gente deixa é que

os requests que que queiram assistir algo que não seja o show é d Cash Miss vão pro pro S3 não tem problema e Cara eu acho que a gente só não não atualiza Cash acho que a gente deixa o show é inteiro no no servidor se possível eu tô só imaginando que a dificuldade pode ser porque por exemplo se a gente for se for uma hora de vídeo é tranquilo Se lançar por exemplo uma temporada inteira de sei lá 20 30 horas Aí complicou que aí não não vai não vai ser o suficiente é deve

ter alguma forma em que a gente consegue fazer um um Cash que e não seja o less recently Used né algum outro tipo de Cash que que seja tenha um certo peso por tempo então vou imaginar que na última uma hora a gente vai pegar os chunks mais acessados nessa uma hora eu acho que isso aqui seria uma um um algoritmo né razoável para mudar a nossa Cash que que você acha faz sentido acho que faz sentido então a gente pegaria os a cada hora a gente tentaria fazer uma Estimativa de qual foi o show

mais extremado naquele período de tempo e aí baseado nisso a gente tomaria a decisão eh de quem expurgar e quem manter isso fechou acho que faz sentido mas alguma coisa que você iria preparar para para is V Ah sim né a gente tava só falando de Chunk de meta dadas Tá calma hum cara assim ó uma vez eu já trabalhei com com streaming de de dados em evento grande não não é era os dados em si eles eram bem leves Então esse não era o gargalo e para fazer a entrega de tipo para conseguir escalar

pro número de request que a gente precisava A gente jogou a gente não usou um server né A gente jogou tudo em lambda porque aí a gente conseguia ter o número de basicamente o número de requests que a gente precisava era ent a Gente Nem precisou mensurar muitos quantos requests iam ser só né só fazer uma estimativa para ver se o custo tava dentro do que a gente queria mas a gente não vai migrar uma arquitetura de servidores para lâmbda para um evento isso não não é algo que faça muito sentido a gente precisa de

uma forma de escalar isso daqui ISO que não vai performar bem esses dois servidores vamos trazer eles para um para um canto aqui e olha eu acho que assim você a gente com certeza vai ter aut scaling nessas C2 né mas o o a scaling ele não ele não não é perfeito e instantâneo Você tem uma né até porque a gente quereria carregar já ter os servidores com a com a Cash inicializado então talvez eu daria um jeito de provisionar manualmente um número de de clusters maior e se se passar do tipo assim se o

número de request for até maior do que a gente precisa aí a gente ainda tem um aut scaling e então vamos imaginar que isso aqui é um cluster de servidores né E se o sei lá o load for maior do que 80% a gente provisiona outro cluster talvez e dessa forma a gente consegue com que o load balancer faça esse provisionamento né eu sei que alguns L baners têm esse tipo de de função de conseguir eh determinar o tráfico e e solicitar que mais clur sejam provisionados Então eu acho que o nosso server precisa ser

algo nesse sentido não sei o que que você pensa sobre tudo isso que eu falei isso faz se faz sentido o que eu tô falando ou se você acha que não não é muito razoável eu acho que faz muito sentido e só tem mais uma pergunta que que é sempre o problema no alfing e não eh eu já entendi que entra ali Ah você é muito bom no escal ia falar que nem precisava fazer essaa perfeito e Mas e a última pergunta sobre out scaling eh quando você definir load de 80% qual qual vai ser

a métrica disso vai ser CPU vai ser quantos requisições ele tá recebendo qual vai ser a sua métrica de Out Skill Deixa eu pensar um pouco nisso eh intuitivamente eu penso que que CPU eu não acho que o número de requests vai ser o que vai limitar a gente eu acho que o gargalo mais o principal gargalo na minha visão parece ser CPU intuitivamente ã o ou CPU ou o Ram talvez não sei se a memória da não sei o quanto de porque o request é algo que não sei a gente provavelmente a gente a

gente conseguiria determinar isso com com algum tipo de de teste eh previamente né você né você faz um um cluster menor do que o que você vai ter no show e você faz um load teste nele como a gente não tem acesso a isso ah eu acho que eu iria de CPU Eu acho que o CPU é que vai que vai pesar mais mas eu não tenho certeza não perfeito e é bom saber como como você tá pensando também é que nem você falou sempre dá para testar isso no mundo real eu só queria ver

qual seria a sua intuição e mais importante porque porque a sua intuição S assim o o o número de requests né eu eu sei factualmente que um pom Macbook consegue lidar com uma quantidade absurda de de requests Se você usar um um serviço de fato preparado para isso né como a gente tá imaginando uma empresa grande e tal a gente não tá a gente não tá usando um um Jungle Zinho para para servir nosso co a gente tem algo de fato preparado e eu acho que cada máquina ia suportar cara sei lá 100.000 requests talvez

e me parece que CPU pode ser o primeiro gargalo e eu acho que requests o request perc não não pesa muito eu acho que tá mais ou na CPU ou na Ram ali um dos dois fechou esse meu pensamento agora um uma última etapa E a gente usou pro blob Storage você até falou que poderia ser um blob Storage genérico genérico ou S3 eu vou puxar para um blob Storage genérico ao invés de S3 Porque o S3 é um serviço já gerido pela aws que acaba simplificando muita coisa Então vamos supor que a gente eh

pegou um blob Storage do kit Hub um blob Storage open source e a gente tá usando ele para deplo só que uma coisa que o time percebeu foi conforme a gente foi botando mais shows conforme o catálogo foi crescendo ele começou a ficar muito devagar em uma única Instância e então o requisito que você recebeu do time que tá lidando com a infra disso é separar em algumas instâncias diferentes como você faria para separar esse blob stor blob Storage por região uhum tá isso é uma não é uma não é uma questão de de só

replicar eu acho porque me parece que o que tá o que tá deixando ele lento é a é a quantidade de dados e não a quantidade de requests faz sentido Exatamente isso exatamente a gente percebeu uma deção baseado no volume Total Então imagina que a gente tem centenas de terab de dados nesse blob Storage e a gente percebeu que toda vez que ele fica com mais de 10 teras ele começa a ter uma degradação violenta na performance uhum Vamos só para eu ter um pouco de espaço Vamos jogar isso aqui um pouco pro pro canto

é isso é uma uma questão de de charging eu o Só uma pergunta meio aleatória os metadados eles são pro vídeo né eles não são pro Chunk pro vídeo perfeito eles são do vídeo tá não Bacana Então a gente eh a gente o que a gente precisa eh é fazer um charg a gente precisa de algo aqui vamos colocar um banco de dados é que esse é esse serviço ele vai ser responsável por linkar Ah aqui do do vídeo com Ah aqui do e blob onde e onde o Chunk se encontra então a minha ideia

é a seguinte e ao invés de ter um blob que tá tá armazenando tudo a gente vai ter aqui um banco de dados que vai fazer esse link entre a chave de qual é o vídeo que eu quero para onde que esses chunks então estão então é a gente vai né esse esse banco de dados ele vai vai me dizer onde tá em qual em qual qual charge desse desse blob tá tá localizado os chunks que a gente quer acessar Tendo tendo isso aqui em mente assim eh eu tô só pensando como é que o

nosso serviço de processamento vai lidar com isso agora Hã e bom eh isso aqui não não vai não vai interferindo o nosso Dynamo de metadados né porque a a quantidade de metadados ela ela é por vídeo isso que pode ser ser mantido mesmo e pode isso honestamente não não faz tanta diferença pode ser qualquer eu acho que qualquer no novo ciclo tá bom ou o cle também não acho que isso aqui vai ser um um problema grande acho talvez no seo seja um pouco mais rápido para esse caso mas o eu quero sa eu estou

pensando em como que a gente vai fazer com que o processing não porque a gente tem o nosso processing o nosso processing service aqui e a gente precisa que exista alguma maneira de por exemplo ele cria um ele cria uma eh uma uma Key do do vídeo né aqui no no no SQL e ele precisa saber para qual blob ele vai enviar esses e esses meta esses esses chunks a gente já tem esse link eu só tô tentando pensar em como é que vai ser o processo de tomada de decisão de Para qual lugar eu

envio os chunks que que você acha você tem você tem em mente eu tô meio preso nisso não tô conseguindo pode imagina pode propor qualquer algoritmo para fazer essa divisão então se eu entendi direito onde a sua cabeça tá agora é você tem esses dois vídeos vamos falar que o nome do filme é fil um você tem outro filme dois e aí você precisa decidir para qual um dos dois chardes Ele vai e aí podia ser assim Eu sempre gosto de tentar pensar na solução mais simples possível a gente poderia ser randômico né a gente

poderia ter um algoritmo randômico para poder jogar pros dois pode propor qualquer um que vi a sua cabeça de como a primeira interação desse serviço sim o o algoritmo perc um R Robin faz faz sentido tem alguns problemas Quando conforme a gente vai adicionando blobs né alguns vão ficar mais mais pesad ados que outros e eventualmente eu tem uma questão que que o ter hotspots né então você tem uma uma série que é muito popular e ela caiu em um em um blob específico se B que o nosso blob tava degradando com com os dados

e não com os acessos Então acho que R Robin tá razoável para Agora é eu só não sei onde é que esse round robing fica sendo bem sincero eu só não sei quem é que quem é que responde pro press bom a gente pode ter um serviço aqui no meio no meio tem a gente não não tem não tem problema isso aqui vai vai nos dizer e vai fazer o Inter médio aqui essencialmente de de definir qual para qual blob enviar e para fazer o WR no nosso nosso né noqu aqui gostei Então você propôs

o round dring E você também descreveu qual seria o a limitação dele que ele poderia botar blobs que estão muito quentes né que muitas pessoas estão acessando no no mesmo na mesma Instância então a gente poderia ter uma Instância que tem muito eh shows muito acessados outra que não tem tanto mas não era o problema realmente tá correto não era esse o problema que a gente tinha não era acesso era o volume existe também outro outro problema aqui né que é por exemplo com quando esses blobs aqui eles ficarem lentos porque supondo que a gente

inicie só com dois eventualmente eles vão degradar também por causa da quantidade de dados eh se a gente só adicionar mais dois o round Robin ainda tá distribuindo para esses dois que já estão no no limite deles né Então isso que precisaria ser pensado talvez quando eles atingirem certo tamanho né quando eles chegarem sei lá em não sei vamos por 500 vídeos aí a gente faz faz algum algum tipo de de processo para dividir para jogar 250 para cá então aí a gente pode continuar no R jobing desde que a gente faça essa distribuição enfim

aí o problema fica realmente o hotspot Gostei você previu minha última pergunta na verdade Era exatamente isso como a gente faria quando a gente quisesse continuar escalando isso no futur Então você dividiria os já existentes em em Mult Acho que sim é E se a gente né tiver também pensando no hotspot e a gente tiver algum tipo de de Analytics rodando em em algum serviço em algum canto esse analitics poderia nos nos dizer quais vídeos que seriam legais de passar de um pro outro que a gente sabe quais são os mais acessados Mas enfim isso

é outra solução né para outro problema mas massa era isso Valeu ficou ficou bem bacana a solução bacana e que que você acha que que faltou o que que você acha que a gente podia ter feito melhor aqui e o que que foi foi bom e o que que foi que que faltou assim que que você pensa meio um feedback geral da é um feedback geral feedback geral eu gostei bastante que você não complicou mais do que precisava a primeira as primeiras iterações então conforme o tempo foi passando você foi adicionando complexidade então por exemplo

você começou com S2 depois você botou Auto scaling você começou só com o blob Storage depois você adicionou o Dynamo só quando o requisito chegou você não começou com o DNS é baseado em geolocation você só adicionou isso quando migrou de solução O que é bom não é legal você fazer uma solução super complexa no início só que você quer impressionar o o entrevistador porque você sabe muitos termos você sabe muitas coisas é bacana manter manter simples Até a a complexidade surgir gostei bastante eh o todo a arquitetura funciona também daria para construir esse serviço

esse esse serviço bateria todos os requisitos que a gente fez coisas que eu acho que dava pra gente ter explorado mais seria outras formas da gente eh tentar prevenir que o usuário não use mais de quatro sessões Isso é realmente um assunto muito difícil porque não tem muito como você garantir eh que o usário não vai vai usar mais quatro devices porque tem aquela frase né você nunca pode garantir o que o usuário vai rodar no device dele porque o o quem vai est rodando o seu código FR Change e a requisição tudo que vai

vir é do usuário então que nem você e eu gostei que você começou a pensar sobre essas coisas também que o usuário ele pode todo todos eles todos os devices estaram usando o mesmo IP né porque ele pode estar atrás de um roteador até mesmo de um prox que Ele montou um um um DNS pago que ele usa por exemplo e não é uma ciência não tem isso não é resolvido sempre tem formas de burlar mas com certeza por exemplo eu acho que daria pra gente ter explorado mais formas de outras estratégias pra gente tentar

ver por exemplo tentar checar qual show ele tá consumindo se é o mesmo todos os devices são acessando no mesmo show ou se a gente tá recebendo muitas requisições para shows diferentes daquele device daquele usuário né ou e botar alguns limites assim É sempre melhor eh sempre tentar dar o seu melhor para prevenir sabendo que você nunca vai conseguir garantir 100% que ele não tá burlando essa regra e o último o o algoritmo cara o robing ele funciona que nem você falou a única coisa que eu acho que não funcionaria ali pra direita seria o

o processo da gente escalar assim quer dizer funcionaria a gente consegue escalar que nem você falou para mais blob Storage dessa forma sim mas isso requer que a gente sempre esteja aumentando Ou seja a gente saiu de dois para para quatro né e a gente sempre tem essa isso é essa parte já é uma constante difícil pra gente botar na infraestrutura no segundo que sempre a gente tá fazendo essa divisão de de metade do load E durante esse processo Eu nem cheguei a pensar nisso mas talvez tenha alguma disponibilidade durante o período então a gente

poderia ter explorado mais essa forma também de como funcionaria esse processo e talvez mais algumas opções eu gostei do R Jing realmente não o problema não era volume de acesso era só o volume de dados então funciona R para resolver o problema que foi dado Mas seria legal ver como outras estratégias de a gente aumentar o chat beleza bacana tá isso então foi sobre eh questão técnica assim né agora o que que você acha que é importante em comportamental mesmo como as pessoas se se porta na entrevista Que tipo de pergunta que ela faz como

é que ela interage e utiliza do entrevistador então uma coisa que você faz muito bem mas pode até parecer que é por causa do vídeo que você tá sempre falando mas não é eu imagino que é assim que realmente que você não eu sempre faço isso na verdade fazer vídeos me ajudou a fazer isso porque antes eu era mais quieto em entrevista só que tipo como eu fui fazendo muito vídeo eu fui sempre explicando o que que eu tava fazendo então toda vez que eu participo de uma entrevista parece que eu tô gravando um vídeo

perfeito Exatamente isso e você tava sempre comunicando então por exemplo na parte do DNS Eu gostei muito daquela sessão que você falou assim é eu não sei se o DNS ele consegue resolver para geolocation se não resolver eu tenho essa outra alternativa então nisso você ao invés de você ficar quieto durante 10 segundos só pensando para você mesmo e eu não saber onde Quais são as suas dúvidas Quais são as suas limitações e o que você tá pensando você foi entregando o valor enquanto você explicava você foi sendo honesto e transparente sobre as coisas que

você não tinha certeza e aí você foi colocando mais coisas então por exemplo se você não tivesse me falado que você não tem certeza se o DNS faz o location ou não e você só tivesse botado aquele serviço eh eu não ia ter o contexto eu só ia achar que você que ia ser a única opção que você vê é ter um serviço para fazer essa resolução Então você mostrou que você vê opções e você só não tem certeza se Elas seriam opções Nesse contexto ou não então é bem bacana ir falando mesmo se for

dúvida mesmo se for não só falando que você tem certeza mas falando também quando você não tem certeza sobre as suas dúvidas sobre eh o o que você tá pensando e o seu processo de raciocínio sobre o problema isso foi muito bom É eu acho que eu eu geralmente porque Ah e as pessoas às vezes acham que é ruim você falar que você não sabe alguma coisa só que é é é muito transparente pelo menos na minha visão é muito transparente pro entrevistador Quando que você tá bullshit assim quando que você tá só jogando Buzz

Words para ver se se cola e quando que você tá tipo assim se tu explicitar o teu processo de raciocínio e deixar claro onde que tu Quais são as as teus limites ali né O que que você conhece o que que você não conhece eu acho que essa transparência Vale bastante eu acho que o trador consegue ter muito mais acesso à sua linha de raciocínio do que eu só tipo se eu chegasse no mesmo desenho só jogando um monte de termo atrás de termo essa entrevista teria sido péssima e ter sido horrível Então isso é

até um um bom ponto é muito melhor uma pessoa que não tem certeza sobre algumas coisas e é honesta e transparência sobre isso do que uma pessoa que é confiante e está errada então imagina se você confiantemente falasse alguma coisa completamente errado isso é muito 10 vezes pior do que você falar que você não tem certeza sobre alguma coisa e ninguém é especialista em tudo então por exemplo imagina você tá entrevistando o John kmac Talvez ele não saiba muito sobre redis ele vai ter dúvidas e é muito melhor você trabalhar com uma pessoa que é

transparente sobre até onde o conhecimento vai e até onde não vai porque aí você pode explorar junto do que uma pessoa que finge ser especialista em tudo e comete uma atrocidade e ninguém do time sabe que que aquele problema tá acontecendo que ela nunca falou que ela não tem certeza sobre aqu sim até porque né na na maioria das vezes você não tá sendo contratado para para desenhar esse serviço do zero É muito raro a empresa chegar e falar não eu preciso contratar alguém que vai desenhar um hum vai vai escalar o meu meu Netflix

aqui do zero a 100 milhões de usuários não acontece é o que a entrevista tá tentando determinar é é se tu de fato tem tem um conhecimento razoável ali né do necessário para para aquela vaga E como que tu trabalha como é que é o teu processo de decisão Como que Como que tu se porta assim se se tu é uma pessoa decente de trabalhar com um ou se tu é alguém que vai só sair cuspindo soluções e é isso aí sabe mais o mais um argumento sobre sem prol da dúvida porque por exemplo vamos

falar que você tá construindo esse sistema você sabe que você tem dúvida nesse DNA se você falou sobre isso então você pesquisaria você jogaria no Google e você teria a sua resposta em 10 segundos agora se você não tem essa dúvida se ou ou se você não sabe nem sobre o que você tem dúvida aí é um problema muito mais difícil porque você não pesquisaria porque você nem sabe que a dúvida existe então se você fala eu não tenho certeza se o DNS consegue resolver por geolocation ou não isso para mim é basicamente você saber

porque você vai pesquisar e você vai ter resposta em 10 segundos é muito melhor do que você guardar essa dúvida para si e eu falar pô eu nem acho que o Augusto nunca resolveria isso porque nem a dúvida ele tem então eu não saberia que pesquisar é você nem sabe o que que é uma uma limitação do seu conhecimento né você não faz ideia que tem um problema para ser resolvido Exatamente exatamente não tem como você pesquisar Google Toma aqui o meu assistem design e me fala as coisas que eu não sei sobre ele isso

é muito mais difícil é mas Bom eu acho que é isso se tu quiser falar alguma coisa pr pra gente encerrar aqui não sei se é você quer falar onde que a pessoa pode te te acompanhar é e cara valeu demais por por essa sessão aust e quem quiser me seguir eu sou LT Menezes no e eu posto mais conteúdo no Twitter é o o Leo é figurinha carambada aqui do do canal tem tem vários vídeos com ele tem lives com ele enfim eh prazer foi muito bom acho que foi AAS entrevistas acho que o

pessoal vai conseguir tirar tipo aprender bastante coisa sobre como funciona né porque não é um tipo de entrevista tão comum assim de se esbarrar então no Brasil elas é é mais incomum Eu acho que isso aqui pode ser bastante útil para quem tá aplicando para fora mesmo eu vejo muito mais esse tipo de entrevista na Europa e nos Estados Unidos do que eu vejo no Brasil então é é um GAP um pouquinho difícil de se passar né porque você tá fazendo muitas entrevistas pro Brasil É raro você você cair no System design eu acho e

quando você começa a fazer para outros países é mais comum então Enfim acho que é isso valeu pessoal Valeu galera encerrar