Sobre o programa que ele usa para desenhar, fazer o rascunho no vídeo: Excalidraw, é gratuito... pode ser acessado via navegador ou até mesmo como um plugin dentro do software Obsidian
Opa, excelente video! Para galera que ainda não passou por um processo seletivo de TI, esse conteúdo dá um norte muito bom. Só alguns detalhes que acho importante comentar: - AWS S3 não é um blob storage, mas sim um object storage. Há semelhanças, porém são serviços distintos que lidam de forma diferente com os objetos. - Faltou mencionar o protocolo de comunicação entre o cliente e o LB. UDP ou TCP? - Não é correto colocar um loadbalancer como camada de comunicação com o cliente. Loadbalancer é um simples serviço de distribuição de carga, e não possui recursos avançados de controle de tráfego. Por exemplo, vc não consegue setar request rate limit no loadbalancer, por isso o ideal seria colocar um API Gateway entre o cliente e o LB. - AWS WAF para controle de tráfego por região.
Em relação ao penúltimo tópico, sobre LB, teria algum cenário específico que o LB ficaria antes do Gateway, invertendo a ordem que você propôs? Eu estava com essa exata dúvida e praticamente todas fontes de informações dizia que dependia da situação
@@gusta4353 De fato depende. Acho que fui muito incisivo no meu comentário. haha Por exemplo, se vc tem sua infra na AWS e quer utilizar o AWS Certificate Manager (ACM) para gerenciar seus certificados, provavelmente vc vai ter que colocar um AWS LB na frente do seu API Gateway. Dessa forma vc consegue associar os certificados do ACM no seu LB e fazer o SSL termination ali mesmo. Então nesse caso o seu API Gateway ficaria depois do LB.
@@sr.cenora Incorreto. Vc pode (e é até importante) que o api gateway seja a porta de entrada. Ele permite associar certificados e fazer o upstream pra um load balancer. Eu ainda colocaria o lb com ip privado, garantindo que ele não seja acessível sem passar pelo api gateway. Aproveitando o ponto do api gateway, a autenticação já poderia ser colocada lá, com um cognito.
@@tkrafael Eu acho que vc não entendeu meu ponto. Eu disse que se vc quiser utilizar o AWS Certificate Manager como serviço de gerenciamento de certificados, vc poderia colocar um load balancer na frente do API Gateway (não estou falando do serviço AWS API Gateway aqui). Vc não consegue associar certificados gerenciados pela AWS à serviços não gerenciados pela AWS, tipo um Kong stand-alone.
Top!! Exatas perguntas que eu me fiz aqui ele acabou não abordando. Único ponto é que para controle de trágedo por região é por Route 53 com geolocation. WAF é uma camada de segurança a mais.
Valeu, irmão! 🔥 Gosto principalmente de como você diz "eu não sei" várias vezes - só porque a vaga é pra Sênior, não quer dizer wue você precisa saber tudo. Aliás, pra mim, um dos indicadores de senioridade é justamente saber dizer "não sei" quando necessário.
Aprendi demais assistindo, parabéns pelo conteúdo de grande valor para nós desenvolvedores. Este material é sem dúvida um ponto de destaque porque me trouxe uma visão ampla e até simples de perceber as nuances entre entrevistador-entrevistado que no final vai ser o ponto de decisão da empresa para contratação do candidato.
Não acredito que assisti uma entrevista de 45 minutos para Dev Senior hahah, não sou desenvolvedora, sou designer, e quando ele começou a falar de System Design pensei que ia falar de Design System e fiquei confusa. No mais, que assertividade esse cara têm, baita vídeo igual o Lucas Montano comentou!
O algoritmo do youtube pode ser uma merda as vezes mas dessa vez ele acertou. Vídeo muito top mesmo não sou DEV mas curtir muito a entrevista deu pra ter uma noção de como é e o tanto que o entrevistado é inteligente, parabéns pelo vídeo.
Gostei muito, você é realmente absurdo nos conteúdos. Assim, vendo de longe eu adicionaria WAF para as validações de países e regras de redirecionamento (o WAF já tem ambas features). No quesito do Cache, eu utilizaria CDN sim, no caso da AWS, Cloudfront, ele faz o papel de guardar o conteúdo estático de algumas rotas, incluindo vídeos e assim você não precisa se preocupar, em segundo caso configurar o Nginx (que você vai usar mesmo que indiretamente lá no load balancer) pra realizar cache também seria uma boa. Agora, ao quesito do autoscaling, acho que sua ideia de alterar na mão é o certo, eu faria o seguinte, caso você use EKS, nesse tipo de sistema acredito que seja até o recomendável, em segundo caso, ECS. Criar um autoscaling por nodes acho que seria o mais correto, eu alteraria a quantidade minimas de nodes para maxima e deixaria a quantidade atual (desire size) no mínimo e aumentaria bastante a quantidade de nodes, pra que escalassem automaticamente e no Autoscaling você pode configurar % de node pra escalar
Obrigado pela dica, irmão. - Precisa replicar toda a infra numa nova região para servir múltiplos países? Só o CDN cacheando os vídeos, e esse cache estando em diferentes regiões, é suficiente, certo? - Sobre o WAF - ele consegue acessar os metadados no DB e validar se aquele vídeo pode ou não ser reproduzido naquela região? Eu pensei em algo diferente - provavelmente em algum momento da infra, o país (country code) é injetado no request. De repente o próprio service pode fazer essa validação?
@@StanleySathler WAF é uma camada de segurança, não para redirecionamento, balanceamento ou divisão de trafego. Para isso pode-se utilizar o Route53 com regras como Geolocation ou Geoproximity ou até mesmo Latency. Ambas regras no Route53 podem ter verificações de integridade, por exemplo. O WAF (Web Application Firewall) é uma ferramenta poderosa que adiciona uma camada a mais de proteção. Embora ele possibilite criar regras baseadas em Geolocalização o objetivo com a regra é bloquear ou permitir o trafego dentro da rede.
Cara, acho que depois do Fábio Akita, o teu conteúdo é o melhor conteúdo sobre computação do RU-vid. Tem muito conteúdo por aí muito raso, que não agrega quase nada, mas o tipo de coisa que você oferece aqui é SENSACIONAL!
no minuto : 33:15 um Cassandra resolveria seu problema de rebalanceamento, e escala. Em vez de voce usar round robin pra balancear os nodes (que nao iria escalar como voce queria), voce deveria usar Consistent Hashing pra implementar e distribuicao via hash em topologia Anel.
Legal , no geral. Faltou do lado do entrevistar, uns "Olha, essa decisão é sua, não minha". Isso é classico, para adicionar um nervosismo ao entrevistado e ver como ele se sai nesse ponto. Ficou muito friendly.
Sobre a parte de garantir que no máximo 4 devices façam streaming, esse serviço pode usar um streaming socket pra manter as conexões abertas e mandar os chuncks, essa conexão pode estar atrelada ao usuário ao invés da sessão, e que pode contar quantos sockets estão abertos para cada usuário e evitar um session forging. Eu sei que o objetivo é manter a visualização em um nível mais alto, mas alguns requisitos exigem ir um pouco mais baixo nível, e esse acho que é um bom exemplo.
Minhas considerações pra essa solução são sobre escala e sobre custo. Talvez usar uma solução mais simples (uma espécie de lock num redis) que não deixa mais de 4 acessos na mesma conta, mas só na api de resolução de url dos chunks, resolveria. Como não vai existir solução perfeita, a ideia desses bloqueios é tornar "caro" pra pessoa que está forjando a ponto de não valer a pena, ou seja, é mais fácil ela criar novas contas (ou mudar o plano).
Acho que o maior desafio foi - como decidir quais conexões são do "mesmo usuário, mas dispositivos diferentes"? O IP não serve porque todos podem estar na mesma rede doméstica, certo? Qual outra informação pode ser usada para identificar o device e saber que dois devices são distintos?
Uma coisa que acho que faltou, seria, por exemplo, verificar quantos chunks diferentes o usuário está recebendo, se é maior ou igual a 4, além das checagens básicas.
A CDN pode ficar à frente do LB. Caso encontre o recurso desejado, ele nem cairia no LB. Para dividir conteúdo por geolocalizacao, poderia ter uma WAF antes do LB onde seria feito a pesquisa originária do IP vindo do request para uma localidade, adicionando essa informação. Sabemos que VPNs podem forjar localização mas é o mundo como é. Uma boa ideia também, na minha opinião, seria um service discovery onde cada serviço que sobe no seu cluster, registraria nesse discovery, qual é o serviço e uma API gateway para servir à política de serviços. Assim ficaria melhor para saber no API gateway, qual serviço chamar.
O WAF é importante colocar antes do alb ou do api gateway, concordo. Porém sobre o waf fazer o streaming do vídeo, a conta não vai fechar, o waf é bem caro
Esta falando do AWS WAF? Se sim o WAF é uma camada de segurança, não para redirecionamento. Para isso pode-se utilizar o Route53 com regras como Geolocation ou Geoproximity ou até mesmo Latency. Ambas regras no Route53 podem ter verificações de integridade, por exemplo. O WAF (Web Application Firewall) é uma ferramenta poderosa que adiciona uma camada a mais de proteção. Embora ele possibilite criar regras baseadas em Geolocalização o objetivo com a regra é bloquear ou permitir o trafego dentro da rede.
Para limitar a 4 dispositivos você pode controlar de algumas formas. Uma delas seria pelo próprio conteúdo. Não faz sentido todos os dispositivos estarem baixando exatamente o mesmo chunk ao exato mesmo tempo. Então, em teoria, estariam baixando chunks diferentes. Dessa forma você contabiliza quantos estão sendo baixados e determina o número de dispositivos. Outra forma seria pelo uso da banda. Se tiver um cap de 5MB/s ( resultado de estudos anteriores, pode variar muito ), e aquele login está usando 50MB, em teoria tem 10 devices baixando. Existem outras maneiras também, de complementar essa segurança. Sobre a escolha do blob, ao invés de randômico, eu provavelmente sugeriria escolher o blob pela % de uso atual. O mais "leve" recebe o próximo chunk. Dessa forma o balanceamento é íntegro. Sobre a geolocalização, na minha opinião, isso tem que estar na mão do dispositivo/OS. Por exemplo, o app do celular pode já puxar a localização e o idioma do dispositivo. Num 2o momento somente uma validação deveria ocorrer no ambiente externo, frequentemente ou não, a depender do volume de problema que isso vai gerar, e se isso afeta ou não o core do produto.
A questão do streaming em mais dispositivos não precisa ser redesenhada. Existem soluções prontas (widevine por exemplo) que já fazem isso. Porém eu faria o streaming diretamente do S3 usando uma url gerada com expiração um pouco maior que o tempo do arquivo. E um banco de controle com expiração dessas urls, garantindo que não seja possível hvar mais de 4 urls ativas. Usar o widevine talvez seria uma opção, porém vejo que seria mais caro. Sobre a geolocalização, é possível usar o route53 pra resolver endereços diferentes com base na origem. É uma opção. E por fim, eu não concordo em replicar o ambiente pra múltiplas regiões se não é um requisito de alta disponibilidade. Um endpoint colocado em us-east-1 por exemplo, tem um roundtrip razoável em praticamente todas as regiões principais dos continentes. E colocaria o CDN (ou talvez um haproxy/nginx nas regiões mais usadas) pra esconder o S3 e tornar o acesso mais rápido (também cortar custo de egress entre regiões)
Acredito que dar para resolver de uma forma mais simplificada, Usuário tem uma conta, com isso e possível controlar o número de acessos, como são dados leves e possível ter um servidor único para todo o mundo, dando possibilidade de acesso em qualquer lugar, a sessão e armazenada localmente e para acesso teria o log de IP + Nome da máquina, assim vai limitar o número de acessos mesmo sendo realizado no mesmo IP. Teria um LB ou um serviço tipo o Cloudflare para controlar o país ou estado que o usuário vai fazer o acesso, teria 1 servidor CND por pais ou estado com todos os vídeos armazenados, o banco de dados seria apenas para armazenar o caminho dos vídeos para não consumir o banco, usuário faz a requisição do vídeo, o LB decide de qual servidor buscar a informação, o vídeo e solicitado e neste momento vai fazer o Streaming do vídeo, precisa de um serviço para replicar os vídeos de vários servidores.
Eu como frontend me senti totalmente largado, o frontend vai segurar esse tanto de acesso sem nenhuma estrutura? Kkkk Eu pensei em várias coisas de como o frontend deveria se portar pra entregar isso, pra algo como o Cloudfront limitar acessos regionais e mais. Mas queria ter visto isso ser falado.
Acho que o cache dos chunks deveriam ficar em um redis cluster, onde o cache seria provisionado conforme demanda de forma independente do servidor. De forma que um filme muito visualizado seria fornecido para todas as instancias do mesmo cache. Estagiário falando rapaziada. kk
Você pode utilizar do "zero knowledge" criar um algoritmo no cliente e no back que gera uma chave privada com base em determinadas informações do usuário para criar um base64 que guarda todas as informações necessárias do lado do cliente e enviar para o servidor. Assim você consegue levar informações do front para o back e para modificar a pessoa deveria conhecer do algoritmo.
@@eliseumds o JWT iria ficar com a chave privada exposta, isso não é muito interessante, o atacante poderia modificar as informações. A ideia era validar o conteúdo da informação se é verdadeiro, igual o cartão chave do bradesco. Pra isso o usuário deveria conhecer do algoritmo para modificar a informação.
Achei foda quando ele dizia diversas vezes q não sabia de algo ou q não sabia de algo, como um iniciante na programação eu tinha muito medo de dizer dizer q não sabia de algo e perder a minha credibilidade por exemplo.
E melhor dizer que não sabe e conseguir entrar na empresa sabendo das limitações. Se entrar dizendo que sabe e depois não dar conta, é pior. Em empresas mais organizadas, a união faz a força. As pessoas acabam se complementando.
Isso foi uma entrevista? Pareceu uma consultoria de projeto, lembra a galera querendo o projeto elétrico para poder "cotar" com a concorrência hahahah Isso parece o briefing inicial de um projeto onde dois chefes de equipe estão debatendo os alinhamentos. Quando será a próxima entrevista? Bora criar uma playlist de "auto ajuda" para os outros ahahhah
11:32 Eu faria o seguinte, UUID com de cada device que o usuário está usando no momento, grava no redis, caso existam mais de 4 no redis retorna um erro, se não, continua e segue a vida, na hora que o usuário parar de consumir esse UUID, seja por que fechou a aplicação, seja por que parou de clicar e entrou naquela tela de "Você está assistindo ainda?" vai ser retirado esse UUID do redis.
@@gustavolol3 você não entendeu, independente de quais são os devices, pode ser o mesmo 4 vezes, se existir um quinto vai dar erro, é o que a netflix faz, você toma um erro mesmo se tiver usando 2 abas no mesmo dispositivo
Mas e aí, o Augusto passou ou não? Qual seria a proposta para esse nível de entrevista? 150k/yr? :D Brincadeiras à parte, é possível aprender sobre esse tipo de arquitetura sem ter experiência desenvolvendo produtos deste tipo? Eu consigo aprender a como montar um serviço/produto de streaming de videos apenas com conteúdo teórico, como livros? Caso contrário, como aprender isso de forma sólida?
Métrica de auto scale definiria por quantidade de request fazendo uma estimativa antes de quanto uma request gasta e quanto tem nossa maquina custo-beneficio e deixaria sempre 1 sobrando, exemplo: bateu 80% das requests, teria outro servidores um a 3 eu acho, já ligados esperando a entrada das requests ou então usava lambda pra tudo msm mas só cuidado com o DDOS by um deb mobile kkkkkkkkk
Oitmo video, eu fiquei com uma duvida no auth apontando pro load balancer, voces falaram que precisariam de algo para verificar as permissões do usuario, como que voces fariam para ter controle disso tudo?? voces conseguiriam colocar todas essas informacoes no banco de dados do oAuth??
tenho uma questão, no video vc "perdeu o pensamento" e perguntou ao entrevistador para onde ir agora, para obter uma indicação do melhor caminho a tomar, esse tipo de perguntas pode ser feito numa entrevista real? os entrevistadores acham isso algo positivo?
