Arquitetura do sistema Netflix

Vamos discutir como projetar a Netflix.

Acredito que todos gostam de assistir séries dramáticas e filmes através de certos aplicativos. Eu gosto da Netflix, mas hoje eu não estou recomendando nenhum filme, em vez disso, eu quero mostrar a lógica do sistema nos bastidores o que é bastante incrível.

Requisito funcional

Criar contas, fazer login e excluir a conta
Inscreva-se ou não assine diferentes planos
Permitir que os usuários tenham e manuseiem várias contas
Permitir que os usuários assistam vídeos
Permitir que os usuários baixem e assistam ao modo offline
Permitir que os usuários pesquisem e descubram o vídeo através do título de vídeo
Os desenvolvedores da Netflix podem enviar vídeos do backend e mostrá-los na plataforma
A plataforma mostrará a tendência, os vídeos mais populares e por categoria que fácil para os usuários escolherem
seleção de idiomas para legendas para que os usuários possam assistir a qualquer vídeo mesmo não falar os idiomas
Agrupamento de vídeos (séries de TV, séries dramáticas, séries de filmes e tratam cada vídeo como independente)
As análises também fornecem sugestões ou recomendações do usuário para o tipo semelhante de vídeos aos usuários com base no comportamento do usuário
Sincronizar para o dispositivo diferente sob a mesma conta, o que significa que os usuários podem usar um dispositivo diferente para continuar assistindo o mesmo episódio sem replay
Reprodução 24 horas por dia, 7/07
Fallback

Requisitos não funcionais

Os usuários podem transmitir vídeos em tempo real sem qualquer problema de atraso ou latência
O sistema será altamente confiável
Alta disponibilidade
Escalabilidade
Os dados de vídeo são duráveis e fáceis de serem acessíveis

Estimativa de Capacidade

Vamos fazer um pouco de matemática para estimar a largura de banda e armazenamento necessários

Suposições

Número total de usuários ativos diários = 100 milhões
O pico de usuários ativos diários, 100 milhões * 3 = 300 milhões
O pico máximo de usuários ativos diários em 3 meses, 300 milhões * 2 = 600 milhões
O número médio de vídeos assistidos por cada usuário por dia = 5
O tamanho médio de um vídeo = 500 MB
O número médio de vídeos carregados por dia a partir do backend = 1.000
Número total de vídeos assistidos por dia = 100 milhões *5 =500 milhões
Total de vídeo de pico por dia = 1,5 bilhão
Total máximo de pico de vídeo por dia = 3 bilhões
Saída total por dia = 500 milhões * 500 MB = 250 PB (Peta Byte)
Largura de banda Egress = 29,1GB/seg
Entrada total para upload = 1.000 * 500MB = 500GB
Largura de banda ingress =5,8MB/seg
Armazenamento Total necessário em 5 anos = 500 GB * 5 * 365 = 912,5 TB (observe que a Netflix cria vários formatos e resoluções para cada vídeo otimizado para diferentes tipos de dispositivos. Assim, o armazenamento será de mais de 912,5 TB.

Os componentes do sistema

O design detalhado do componente

Aplicativo do cliente

Mobile (Apple ios, androis os, huawei OS e etc)
Tablet (Ipad, tablet Android, windows)
TV
Laptop ou computador

React.js é usado para escrever o front-end devido à sua velocidade de carregamento/inicialização, durabilidade/modularidade e desempenho em tempo de execução.

Backend

A Netflix começou a implementar as arquiteturas de microsserviços em 2011 completamente para que seu sistema baseado em nuvem gerenciasse a execução dessas cargas de trabalho. Possui pequenos componentes de software gerenciáveis no nível de API, o que permite e atende solicitações de aplicativos e sites. Os microsserviços dependem uns dos outros internamente para solicitações e busca de dados. Há Java, MySQL, Gluster, Apache Tomcat, Chukwa, Cassandra, KAFKA e Hadoop para fortalecer o sistema backend. Além do streaming de vídeos, o backend lida com tudo, como processamento de vídeos, onboarding de novos conteúdos, gerenciamento de tráfego de rede e distribuição de recursos em servidores em todo o mundo. Atualmente, a Netflix adota a AWS (Amazon Web Services).

O processamento de dados envolve todos os eventos necessários após um clique no vídeo, é preciso nanossegundos para processar o vídeo e transmiti-lo para o usuário. Há cerca de 600 bilhões de eventos diários, resultando em dados de 1,5PB, e nos horários de pico (noite e noite), há cerca de 8 milhões de eventos por segundo. Eventos são atividades de interface do usuário, atividades de visualização de vídeo, erros de registro, solução de problemas, eventos diagnósticos, eventos de processamento e eventos de desempenho. mas todos esses eventos são feitos usando Kafka e Apache Chukwe.

Kafka e Apache Chukwe

para ingerir os dados que são produzidos em uma parte diferente do sistema.
Apache Chukwe é um sistema de coleta de dados de código aberto para coletar registros ou eventos de um sistema distribuído. Ele é construído em cima do HDFS e da estrutura de redução de mapas. Ele vem com os recursos de escalabilidade e robustez de Hadoop. Além disso, inclui muitos kits de ferramentas poderosos e flexíveis para exibir, monitorar e analisar o resultado. Chukwe coleta os eventos de diferentes partes do sistema e de Chukwe você pode fazer monitoramento, análise ou você pode usar o painel de instrumentos para ver os eventos. Chukwe escreve o evento no formato de sequência de arquivos Hadoop (S3). Depois disso, a equipe do Big Data processa esses arquivos S3 Hadoop e grava Colmeia no formato de dados do Parquet. Esse processo é chamado de processamento em lote, que basicamente escaneia todos os dados na frequência horária ou diária. Para enviar eventos on-line ao EMR/S3, a Chukwa também fornece tráfego para o Kafka (portão principal no processamento de dados em tempo real). Kafka é responsável por mover dados da frente kafka para várias pias: S3, Elasticsearch e Kafka secundária. O encaminhamento dessas mensagens é feito usando a estrutura Apache Samja. O tráfego enviado pelo Chukwe pode ser cheio ou filtrado, então às vezes você pode ter que aplicar mais filtragem nos fluxos Kafka. Essa é a razão pela qual consideramos que o roteador leva de um tópico Kafka para um tópico kafka diferente.

Pesquisa elástica

A Netflix está executando aproximadamente 150 clusters de pesquisa elástica e 3.500 hosts com instâncias.
A Netflix está usando uma busca elástica para visualização de dados, suporte ao cliente e para alguma detecção de erros no sistema. Por exemplo, se um cliente não conseguir reproduzir o vídeo, então o executivo de atendimento ao cliente resolverá esse problema usando pesquisa elástica. A equipe de reprodução vai para a busca elástica e busca o usuário para saber por que o vídeo não está sendo reproduzido no dispositivo do usuário. Eles conhecem todas as informações e eventos que acontecem para esse usuário em particular. Eles podem saber o que causou o erro na transmissão de vídeo. A busca elástica também é usada pelo administrador para acompanhar algumas informações. Ele também é usado para acompanhar o uso de recursos e detectar problemas de inscrição ou login.

Backend- Serviços

Serviço de usuário e autenticação (Principal responsável pela autenticação e perfis do usuário. Os dados estarão em um banco de dados relacional como MySQL ou PostgreSQL. Então, rdbms é uma escolha adequada.
Serviço de gerenciamento de assinaturas (Gerenciar a assinatura dos usuários. Uma vez que o processamento de dados por este serviço é de natureza altamente transacional, o RDBMS é uma escolha adequada.
Serviço de Vídeos (Vídeos de surfe para usuários finais. Esta loja de serviços armazena metadados em um RDBMS como MySQL ou PostgreSQL. Para um tempo de resposta rápido, este serviço implementaria um cache de gravação usando um cache na memória como Redis ou Memcached.
Serviço TransCoder (Verificando a qualidade dos vídeos enviados, comprimindo os vídeos com diferentes codecs, criando diferentes resoluções do vídeo. Uma vez que um vídeo é carregado para o serviço Transcoder, ele carregará o mesmo para um armazenamento interno distribuído como um balde S3 e adicionará uma entrada ao banco de dados. Kafka ou RabbitMQ processam uma mensagem na fila. Para que os trabalhadores do backend consumissem mensagens da fila, baixassem o vídeo do balde S3 interno e o transcodificariam para diferentes formatos. Uma vez concluída a transcodificação, o trabalhador carregaria o vídeo em um balde S3 externo e atualizaria o status do vídeo no banco de dados como ativo para visualização pelos usuários finais. O trabalhador também adicionaria uma entrada dos metadados de vídeo no banco de dados de pesquisa que suporta pesquisa de texto completo. Isso permitiria que os usuários finais procurassem vídeos usando seu título ou resumo. Em seguida, o vídeo de um balde S3 externo também seria armazenado em cache sobre um CDN para reduzir a latência melhorando o desempenho de reprodução.
Global Search Service (habilite os usuários finais a procurar um vídeo usando metadados como título, resumo, etc. Elasticsearch ou Solr podem ser usados para suportar a pesquisa de texto completo porque eles são armazenados no Elastic Search DB que permite que os usuários procurem por filmes, séries por título ou quaisquer meta-dados associados ao vídeo. Este serviço também classifica os resultados com base em recência, avaliações, recomendações e popularidade para uma melhor experiência do usuário. Além disso, a pesquisa elástica pode rastrear os eventos dos usuários em casos de falha. Em seguida, a equipe de atendimento ao cliente usa a busca elástica para resolver problemas.

3. Nuvem

A Netflix migrou sua infraestrutura de TI para uma nuvem pública. O serviço de nuvem usado é AWS e Open connect (CDN personalizado da Netflix). Esses 2 serviços em nuvem funcionam paralelamente para processamento de vídeo e entrega de conteúdo para usuários finais.

4. CDN (Rede de Entrega de Conteúdo)

É uma rede de servidores distribuídos globalmente. Quando você reproduza o vídeo, o vídeo exibido em seu dispositivo é transmitido a partir deste componente. Isso reduz significativamente o tempo de resposta à medida que o vídeo é transmitido do servidor mais próximo de sua localização.

Os CDNs replicam conteúdo em vários lugares. Há uma chance de os vídeos estarem mais próximos do usuário e com menos saltos.
As máquinas CDN fazem uso pesado do cache, por isso, mesmo que o vídeo não seja encontrado no servidor, ele também pode ser obtido a partir do cache
Vídeos menos populares (1-20 visualizações por dia) que não são armazenados em cache por CDNs

5. Open Connect

É o CDN global interno ou personalizado da Netflix responsável pelo armazenamento e entrega de filmes e programas de TV para usuários da Netflix globalmente. Nós tocamos o botão de reprodução, o vídeo é transmitido a partir de conexão aberta armazenado em diferentes locais do mundo. Se o vídeo estiver presente lá, o aplicativo do cliente pode acessar facilmente. Se o vídeo não estiver presente lá, a Netflix terá que processar esse vídeo do S3 AWS, então o Open Connect transmitirá esse vídeo para o aplicativo do seu cliente

6. Cache

Redis e Memcached armazenam os dados do banco de dados em par de valor-chave porque podem reduzir o número de acessos ao banco de dados. A partir do servidor cliente, antes do acesso ao banco de dados, o sistema verificará se existem dados no cache. Se ele existe, então contornamos uma viagem de banco de dados. No entanto, se os dados não estão presentes no cache, vamos entrar no banco de dados, obter os dados e preencher o mesmo no cache também. Então, as solicitações subsequentes não chegarão ao banco de dados. Esta estratégia de cache é conhecida como cache de gravação. A política de despejo menos recentemente usada (LRU) para cache de dados porque descartará dados de cache que são mais antigos buscados.

EV cache é na verdade um invólucro em torno de Memcached

A Netflix implantou muitos clusters em várias instâncias do AWS EC2 e esses clusters têm tantos nós de Memcached e eles também têm clientes de cache. Os dados são compartilhados em todo o cluster dentro da mesma zona e várias cópias de cache são armazenadas em nós fragmentados. Toda vez que a gravação acontece com o cliente todos os nós em todos os clusters são atualizados, mas quando a leitura acontece com o cache, ele só é enviado para o cluster mais próximo (nem todos os clusters e nós) e seus nós. No caso, um nó não está disponível e depois lido a partir de um nó disponível diferente. Essa abordagem aumenta o desempenho, a disponibilidade e a confiabilidade.

7. Escalabilidade

Dimensionamento horizontal — adicione mais servidores de aplicativos atrás do balanceador de carga para aumentar a capacidade do serviço.
Replicação do banco de dados — Use o banco de dados relacional na configuração de escravos mestres onde a gravação acontecerá para dominar e ler do escravo. Isso melhorará o desempenho das consultas de leitura, pois elas não serão interrompidas devido à gravação de fechaduras em linhas. Há um leve atraso de replicação (alguns milissegundos) à medida que os dados são escritos para dominar DB e depois propagados para DB escravo.
Fragmentação do banco de dados — distribua dados para vários servidores para executar operações de leitura/gravação de forma eficiente. podemos fragmentar o banco de dados de metadados de vídeo usando video_id. nossa função hash mapeará cada video_id para um servidor aleatório onde podemos armazenar os metadados de vídeo.
fragmentos de cache — Podemos distribuir nosso cache para vários servidores. A Redis tem suporte fora da caixa para particionar os dados em várias instâncias do Redis. O uso de hashing consistente para distribuição de dados garantirá que a carga seja igualmente distribuída se uma instância desaparecer.
Análise do banco de dados — A pesquisa elástica vem com suporte nativo para fragmentação e replicação. O fragmento ajuda a melhorar o tempo de execução da consulta, executando-os em paralelo contra vários fragmentos.

Segurança

HTTPS — criptografando o tráfego entre cliente e servidor por HTTPS. isso garantirá que ninguém no meio seja capaz de ver os dados especialmente senhas
Autenticação — Cada API solicitará o pós-login, fará autenticação verificando a validade de auth_token no cabeçalho HTTP de autorização. Isso garante que os pedidos sejam legítimos.

Resiliência

Replicação — Replica servidores de banco de dados em uma configuração de escravo mestre. Se um dos nódulos cair, outros ocorrem e prestam serviços e continuam funcionando como esperado.
Fila — Usando durante o processamento dos vídeos enviados.

Balanceamento de carga

Vários servidores atrás de um balanceador de carga, haveria redundância. O balanceador de carga fará uma verificação de saúde continuamente nos servidores por trás dele. Se algum servidor morrer, o balanceador de carga deixará de encaminhar o tráfego para ele e o removerá do cluster. Isso garante que as solicitações não falhem devido a um servidor sem resposta.

O balanceador de carga é responsável pelo encaminhamento do tráfego para serviços frontend. Balanceamento de carga elástico, o ELB executa um esquema de balanceamento de carga de 2 níveis onde a carga é equilibrada sobre zonas primeiro e, em seguida, instâncias (servidores).

O primeiro nível consiste em balanceamento de robin redondo baseado em DNS básico. Quando a solicitação aterrissa no primeiro balanceamento de carga, ela é equilibrada em uma das zonas (usando round-robin) que seu ELB está configurado para usar.
O segundo nível é uma matriz de instâncias de balanceador de carga e executa a técnica de Balanceamento Round Robin para distribuir a solicitação através das instâncias que estão por trás dela na mesma zona.

Geo-redundância

Implante réplica exata de nossos serviços em data centers em várias localizações geográficas. O tráfego ainda poderia ser atendido a partir dos data centers restantes.

ZUUL

fornece roteamento dinâmico, monitoramento, resiliência e segurança. Ele fornece roteamento fácil com base em params de consulta, caminhos de URL.

O servidor Netty assume a responsabilidade de lidar com o protocolo de rede, servidor web, gerenciamento de conexão e trabalho de proxying. Quando a solicitação atingir o servidor Netty, ele irá proxy a solicitação para o filtro de entrada.
O filtro de entrada é responsável pela autenticação, roteamento ou decoração da solicitação. Em seguida, encaminha a solicitação para o filtro de ponto final.
O filtro endpoint é usado para retornar uma resposta estática ou para encaminhar a solicitação para o serviço backend (ou origem como o chamamos). Uma vez que recebe a resposta do serviço backend, ele envia a solicitação para o filtro de saída.
O filtro de saída é usado para zipping do conteúdo, calcular as métricas ou adicionar/remover cabeçalhos personalizados. Depois disso, a resposta é enviada de volta para o servidor Netty e, em seguida, é recebida pelo cliente.

Vantagens:

Você pode criar algumas regras e fragmentar o tráfego distribuindo as diferentes partes do tráfego para diferentes servidores.
Os desenvolvedores também podem fazer testes de carga em clusters recém-implantados em algumas máquinas. Eles podem rotear algum tráfego existente nesses clusters e verificar quanta carga um servidor específico pode suportar.
Você também pode testar novos serviços. Ao atualizar o serviço e quiser verificar como ele se comporta com as solicitações de API em tempo real, nesse caso, você pode implantar o serviço específico em um servidor e você pode redirecionar alguma parte do tráfego para o novo serviço para verificar o serviço em tempo real.
Também podemos filtrar a solicitação ruim definindo as regras personalizadas no filtro de ponto final ou firewall.

Histrix

Em um sistema distribuído complexo, um servidor pode contar com a resposta de outro servidor. As dependências desses servidores podem criar latência e todo o sistema pode parar de funcionar se um dos servidores falhar inevitavelmente em algum momento. Para resolver esse problema, podemos isolar o aplicativo host dessas falhas externas. A biblioteca Hystrix foi projetada para fazer este trabalho. Ele ajuda você a controlar as interações entre esses serviços distribuídos adicionando tolerância à latência e lógica de tolerância a falhas. A Hystrix faz isso isolando pontos de acesso entre os serviços, sistema remoto e bibliotecas de terceiros. A biblioteca ajuda.

Pare de falhas em cascata em um sistema distribuído complexo.
controle sobre latência e falha das dependências acessadas (normalmente sobre a rede) através de bibliotecas de clientes de terceiros.
Falhe rápido e rapidamente se recupere.
Recuo e graciosamente degradar quando possível.
Habilite monitoramento, alerta e controle operacional em tempo real.
Pedido de conscientização da concorrência. Loteamento automatizado através do colapso de solicitação

Componentes de bancos de dados

A Netflix usa diferentes DB para armazenar diferentes tipos de arquivos, como SQL e NoSQL para diferentes propósitos.

MySQL

gerenciar títulos de filmes, faturamento e finalidade de transação porque precisa de conformidade COM ACID
A AWS EC2 implantou o MySQL para armazenar os dados
A Netflix tem uma configuração mestre para o MySQL porque o MySQL é construído usando o motor InnoDB em grandes instâncias AWS EC2.
A configuração segue o “protocolo de replicação síncronente”. A replicação dos dados é feita de forma sincronizada, o que afirma que há uma relação mestre entre nós, e qualquer operação de gravação no nó primário será considerada como feita apenas se esses dados forem sincronizados por nós locais e remotos para garantir alta disponibilidade. As consultas de leitura não são tratadas pelo nó principal, são tratadas por réplicas, apenas consultas de gravação são tratadas pelo DB mestre. Em caso de failover, o nó secundário assumirá como nó mestre e lidará bem com a consulta de gravação.

Cassandra (NoSQL)

Cassandra é um NoSQL DB baseado em colunas de código aberto que permite o armazenamento de uma grande quantidade de dados sobre servidores. A Netflix usa isso porque exige esse DB para armazenar o histórico do usuário. Permite o manuseio de grandes quantidades de solicitações de leitura de forma eficiente e otimiza a latência para grandes solicitações de leitura. À medida que a base de usuários crescia, tornou-se difícil armazenar muitas linhas de dados, e é caro e lento. Assim, a Netflix foi projetada com base no prazo e uso recente para o novo DB.
Quando a Netflix começou a adquirir mais usuários, os dados do histórico de visualização de cada membro também começaram a aumentar.
Pegada de armazenamento menor.
Desempenho consistente de leitura/gravação à medida que a visualização por membro cresce (a relação visualização de dados históricos de gravação para leitura é de cerca de 9:1 em Cassandra).
Modelo total de dados desnormalizados
Mais de 50 Aglomerados Cassandra
Mais de 500 nodes
Mais de 30TB de backups diários
Maior aglomerado 72 nós.
1 cluster sobre 250K grava/s
Inicialmente, o histórico de visualização foi armazenado em Cassandra em uma única fila. Quando os usuários começaram a aumentar no Netflix, os tamanhos das linhas, bem como o tamanho geral dos dados, aumentaram. Isso resultou em alto armazenamento, mais custo operacional e desempenho lento do aplicativo. A solução para este problema era comprimir as velhas linhas…

LiveVH (Live viewing history) — apenas dados recentes com atualizações frequentes, um número menor de linhas são armazenados de forma não compactada que é usada para muitas operações como análise, recomendações ao usuário após a realização de ETL (extração, transformação e carregamento).
CompactedVH (histórico de visualização compactado) — dados antigos do histórico de navegação e visualizados pelos usuários são armazenados após compressão com atualizações ocasionais. O tamanho do armazenamento também é diminuído, e apenas uma coluna por linha foi armazenada.

Esquema de banco de dados

Apis

APIs rest são usadas

Inscrição do usuário

Pedir:

POST /api/v1/users
X-API-Key: api_key
{
  name:
  email:
  password:
}

Poste o método HTTP para esta API porque criamos um recurso ou criamos uma nova entrada no DB. X-API-key que é passado para o cabeçalho HTTP é a chave da API para identificar diferentes clientes e fazer limitação de taxas.

Resposta:

201 Created
{
  message:
}

O código de resposta HTTP 201 informa que o usuário se inscreveu com sucesso. Outros códigos HTTP possíveis para casos de falha.

Bad Request
Conflict
Internal Server Error

Pedir:

POST /api/v1/users/session
X-API-Key: api_key
{
  email:
  password:
}

Resposta:

200 OK
{
  auth_token:
}

A API deve retornar uma auth_token que pode ser passada no cabeçalho para chamadas sucessivas de API que requerem autenticação. auth_token podem ser gerados usando JWT.

JWT.IO - Introdução de Tokens web JSON

Saída de assinatura do usuário

Pedir:

DELETE /api/v1/users/session
X-API-Key: api_key
Authorization: auth_token

O método Delete HTTP é usado porque ele excluirá uma entrada de linha no DB, o que significa que estamos terminando uma sessão.

Resposta:

200 OK

O código de resposta HTTP 200 indica um lançamento bem-sucedido.

Subscrever

Pedir:

POST /api/v1/subscription
X-API-Key: api_key
Authorization: auth_token

O método http pós é usado porque cria uma nova assinatura. Estaríamos passando auth-token no cabeçalho autorização para autenticar o usuário.

Resposta:

201 Created
{
  subscription_id:
  plan_name:
  valid_till:
}

O código de resposta HTTP 201 é dado juntamente com subcription_id, plan_name e valid_till para renderizar-os na interface do Usuário.

Possíveis códigos de resposta HTTP de falha:

401 Unauthorized
400 Bad request

Cancelamento de inscrição

Pedir:

DELETE /api/v1/subscription
X-API-Key: api_key
Authorization: auth_token

O método Delete HTTP é usado porque estamos cancelando a assinatura, significa que vamos excluir uma entrada de linha do DB de assinatura.

Resposta:

200 OK

Código HTTP significa que é feito com sucesso.200

Obtenha vídeos

Pedir:

GET /api/v1/videos?page_id=<page_id>
X-API-Key: api_key
Authorization: auth_token

Esta API é usada para renderizar a página inicial do aplicativo uma vez logado. Esta API contém vídeo recomendado que é determinado por modelos de aprendizado de máquina. seria usado para paginação em API e seria usado para solicitar resultados a partir da próxima página.page_idnext_page_id

Resposta:

200 OK
{
  page_id:
  next_page_id:
  videos: [
    {
      id:
      title:
      summary:
      url:
      watched_till:
    },...
  ]
}

Código de status HTTP significa operação bem sucedida.200

Alguns códigos de status de falha:

Unauthorized
Bad request
Too many requests

O código de status HTTP significa que os usuários atingem o limite de taxa e devem esperar algum tempo para fazer solicitações novamente para evitar ataques de Negação de Serviço (DOS).429

Pesquisar API

Pedir:

GET /api/v1/search?q=<query>&page_id=<page_id>
X-API-Key: api_key
Authorization: auth_token

Pesquise um vídeo pelo título

Resposta:

200 OK
{
  page_id:
  next_page_id:
  videos: [
    {
      id:
      title:
      summary:
      url:
      watched_till:
    },...
  ]
}

200 códigos de resposta HTTP significam operações bem sucedidas. em seguida, liste o id, título, resumo, URL e watched_till. pode ser encontrado nenhum também.

Obter vídeo

Pedir:

GET /api/v1/videos/:video_id
X-API-Key: api_key
Authorization: auth_token

Reprodução de um vídeo em particular

Resposta:

200 OK
{
  id:
  title:
  summary:
  url:
  watched_till:
}

200 código de resposta HTTP significa compatível

Alguns códigos de status HTTP de falha:

Unauthorized
Video not found
Too many requests
Internal server error

Carregar API

Pedir:

POST /api/v1/videos
X-API-Key: api_key
Authorization: auth_token
{
  title:
  summary:
  censor_rating:
  video_contents:
}

Carregar vídeo do backend

Resposta:

202 Accepted
{
  video_url:
}

Código de status HTTP 202, o que significa que o vídeo foi gravado para processamento assíncrono e verificações de qualidade. Os resultados do processamento podem ser enviados aos usuários por e-mail ou outros mecanismos de alerta.

Alguns cenários de falha http:

Unauthorized
Bad request
Internal server error

Atualização observada até o timestamp

Pedir:

PUT /api/v1/videos/:video_id/watched_till
X-API-Key: api_key
Authorization: auth_token
{
  watched_till:
}

O método PUT HTTP é usado porque substituímos os outros dados por outras entradas de linha na mesma tabela de banco de dados ou estamos atualizando um recurso no servidor. Esta API seria usada para atualizar o data-hora até que o usuário tenha assistido a um vídeo específico.

Resposta:

200 OK

Código de status HTTP 200 significa operação bem sucedida.

Outros códigos de status HTTP de falha:

Unauthorized
Bad request
Internal server error

Arquitetura de microserviço

Os microsserviços são usados para implantações mais rápidas, pois qualquer mudança nos serviços pode ser feita facilmente. O desempenho de cada serviço pode ser rastreado e se houver algum problema, então ele pode ser rapidamente isolado de outros serviços em execução.

Serviços críticos — para atender os usuários que interagem com eles com muita frequência do serviço. Esses serviços são mantidos independentes de outros serviços para que, para qualquer falha, os usuários possam continuar realizando operações básicas.
Serviços apátridas — para atender solicitações de API aos clientes, de forma que eles continuem a trabalhar com outras instâncias, mesmo que qualquer servidor falhe. Isso garante alta disponibilidade. Por exemplo, os usuários de servidor REST API são os que mais usuários.

Conteúdo de onboarding

Conteúdo é um filme ou show em formato de vídeo. A unidade de processamento são protocolos de entrada, codecs de entrada, codecs de saída e protocolos de saída para atender aos vários dispositivos e velocidades de rede variadas. A qualidade de um vídeo é boa quando você está assistindo o vídeo em alta velocidade de rede. A Netflix cria várias réplicas (aproximadamente 1100-1200) para o mesmo filme com resoluções diferentes. A Netflix quebra o vídeo original em diferentes pedaços menores e usa trabalhadores paralelos na AWS para converter os pedaços em diferentes formatos. Essas unidades de processo são para ajudar a codificar ou transcodificar que é converter o vídeo de um formato para outro, como alterar resoluções, proporção, reduzir o tamanho do arquivo, etc. Depois da transcodificação, uma vez que temos várias cópias dos arquivos para o mesmo filme, esses arquivos são transferidos para o servidor de conexão aberto.

A arquitetura de sistema de alto nível

Arquitetura de dados

Recomendação de filme

Apache Spark e aprendizado de máquina é usado para recomendação de filme. Quando você carrega a primeira página que assiste, há várias linhas de diferentes tipos de filmes.
(Arte) Essas imagens são chamadas de imagens de cabeçalho (miniatura). A Netflix quer o máximo de cliques para os vídeos dos usuários e esses cliques dependem das imagens do cabeçalho. A Netflix tem que escolher a imagem de cabeçalho convincente certa para um vídeo específico. Para isso, a Netflix cria várias obras de arte para um filme específico e exibem essas imagens aleatoriamente para os usuários. Para o mesmo filme, as imagens podem ser diferentes para usuários diferentes. Com base em suas preferências e histórico de visualização, a Netflix prevê que tipo de filmes você mais gosta ou quais atores você mais gosta em um filme. De acordo com o gosto dos usuários, as imagens serão exibidas para eles.
A Netflix analisa os dados e decide que tipo de linhas ou que tipo de filmes devem ser exibidos para você. Isso se baseia nos dados e preferências históricas do usuário. Além disso, a Netflix realiza a triagem dos filmes e calcula o ranking de relevância desses filmes disponíveis em sua plataforma. A maioria dos oleodutos de aprendizado de máquina são executados nestes grandes aglomerados de faíscas. Esses pipelines são então usados para fazer seleção de linhas, classificação, ranking de relevância de títulos e personalização de obras de arte, entre outros. Quando você abre a primeira página do Netflix, você pode ter notado as imagens para cada vídeo.
Agora, a Netflix calcula o número de cliques que uma determinada imagem recebe. Se os cliques para a imagem central do filme forem 1.500 vezes e as outras imagens tiverem menos cliques, então a Netflix fará a imagem central como uma imagem de cabeçalho para o filme Good Will Hunting para sempre. Isso é chamado de data-driven e a Netflix executa a análise de dados com essa abordagem. Para fazer os dados de decisão certos é calculado com base no número de visualizações associadas a cada imagem.
Interação do usuário com o serviço (histórico de visualização e como o usuário avalia outros títulos)
Outros membros com gostos e preferências semelhantes.
Informações de metadados dos vídeos previamente assistidos para um usuário, como títulos, gênero, categorias, atores, ano de lançamento, etc.
O dispositivo do usuário, em que momento um usuário está mais ativo, e por quanto tempo um usuário está ativo.
2 algoritmos

1. Filtragem colaborativa: A ideia dessa filtragem é que se dois usuários tiverem histórico de classificação semelhante, eles se comportarão da mesma forma no futuro. Por exemplo, considere que há duas pessoas. Uma pessoa gostou do filme e classificou o filme com uma boa pontuação. Agora, há uma boa chance de que a outra pessoa também tenha um padrão semelhante e faça a mesma coisa que a primeira pessoa fez.

2. Filtragem baseada em conteúdo: A ideia é filtrar os vídeos semelhantes ao vídeo que um usuário já gostou antes. A filtragem baseada em conteúdo é altamente dependente das informações dos produtos como título de filme, ano de lançamento, atores, o gênero. Então, para implementar essa filtragem é importante saber as informações que descrevem cada item e algum tipo de perfil do usuário descrevendo o que o usuário gosta também é desejável.

Outros recursos:

https://towardsdatascience.com/deep-dive-into-netflixs-recommender-system-341806ae3b48
https://netflixtechblog.com/announcing-suro-backbone-of-netflixs-data-pipeline-5c660ca917b6
https://keypointt.com/2020-05-16-Netflix-playback-dive-deep/
https://www.nexsoftsys.com/articles/how-netflix-backend-system-operates.html
https://elatov.github.io/2021/02/distributed-systems-design-netflix/
https://developpaper.com/design-and-analysis-of-netflix-microservice-architecture/
https://uxdesign.cc/netflix-system-design-ef5802426ad4
https://netflixtechblog.com/tagged/cloud-architecture
https://www.codingninjas.com/blog/2020/12/04/learn-what-is-rest-api-in-10-minutes/
https://about.netflix.com/en/news/how-netflix-works-with-isps-around-the-globe-to-deliver-a-great-viewing-experience
https://www.infoq.com/news/2019/01/netflix-evolution-architecture/
https://www.codekarle.com/system-design/netflix-system-design.html
http://highscalability.com/blog/2015/11/9/a-360-degree-view-of-the-entire-netflix-stack.html

Artigo Original

Requisito funcional

Requisitos não funcionais

Estimativa de Capacidade

Suposições

Os componentes do sistema

O design detalhado do componente

Aplicativo do cliente

Backend

Kafka e Apache Chukwe

Pesquisa elástica

Backend- Serviços

3. Nuvem

4. CDN (Rede de Entrega de Conteúdo)

5. Open Connect

6. Cache

7. Escalabilidade

Segurança

Resiliência

Balanceamento de carga

Geo-redundância

ZUUL

Vantagens:

Histrix

Componentes de bancos de dados

MySQL

Cassandra (NoSQL)

Esquema de banco de dados

Apis

Inscrição do usuário

Login do usuário

Saída de assinatura do usuário

Cancelamento de inscrição

Obtenha vídeos

Pesquisar API

Obter vídeo

Carregar API

Atualização observada até o timestamp

Arquitetura de microserviço

Conteúdo de onboarding

A arquitetura de sistema de alto nível

Arquitetura de dados

Recomendação de filme

Outros recursos: