Como a Netflix Roteia 1 Milhão de Requisições de ML por Segundo do Switchboard ao Lightbulb

Por que Roteamento é Crucial no Serving de ML

Quando você está servindo centenas de tipos e versões de modelos a mais de 1 milhão de requisições por segundo, a forma como você roteia o tráfego para a instância correta se torna uma decisão arquitetural crítica. A plataforma de serving de ML da Netflix alimenta experiências personalizadas em recomendações de títulos, comércio e detecção de fraudes. O desafio central? Como rotear o tráfego para o modelo certo, no shard de cluster certo, para o usuário e caso de uso certos — mantendo a abstração da API simples tanto para serviços clientes quanto para pesquisadores.

Este post (primeiro de uma série do blog técnico da Netflix) detalha a evolução da camada de roteamento: de um proxy centralizado chamado Switchboard para uma abordagem desacoplada e orientada a metadados chamada Lightbulb. É uma aula magistral sobre como equilibrar abstração com realidade operacional em hiperescala.

Por que isso importa para sua arquitetura: Se você está construindo qualquer infraestrutura de serving de modelos — seja para recomendações, detecção de fraudes ou IA generativa — os padrões de roteamento descritos aqui impactam diretamente sua latência, confiabilidade e velocidade de iteração. Os tradeoffs que a Netflix encontrou são universais.

Fonte: Netflix Tech Blog

O Design Original: Switchboard como Proxy Central de Roteamento

A primeira abordagem da Netflix foi o Switchboard, um serviço customizado que atuava como ponto único de entrada para todas as requisições de inferência de modelos. Ele ficava diretamente no caminho da requisição, realizando roteamento sensível ao contexto e enriquecimento da requisição.

Capacidades Principais

• Abstração Comum para Clientes: Os clientes precisavam integrar apenas uma vez. Depois disso, iterações de modelo, experimentos A/B e migrações de shard ficavam opacos para eles.
• Roteamento Sensível ao Contexto: O Switchboard podia rotear com base no dispositivo do usuário, localidade, superfície de ranking (homepage vs. busca) ou alocação de teste A/B.
• Divisão Dinâmica de Tráfego: Deployments canary e lançamentos graduais em tempo real.
• Versionamento e Ciclo de Vida de Modelos: Teste em modo shadow, rollbacks instantâneos.

A Cola: Regras do Switchboard

Os pesquisadores definiam a lógica de roteamento via uma configuração JavaScript:

/**
 * Regra de configuração escrita por um Pesquisador de Modelos para adicionar um experimento A/B.
 * Célula 1: Usa o modelo padrão, atualmente em produção
 * Células 2 e 3: Usam diferentes modelos experimentais (candidatos)
 */
function defineAB12345Rule() {
  const abTestId = 12345;
  const objectives = Objectives.ContinueWatchingRanking;
  const abTestCellToModel = {
    1: {name: "netflix-continue-watching-model-default"},
    2: {name: "netflix-continue-watching-model-cell-2"},
    3: {name: "netflix-continue-watching-model-cell-3"}
  };
  return {
    cellToModel: abTestCellToModel,
    abTestId: abTestId,
    targetObjectives: [objectives],
    modelInputType: constants.TITLE_INPUT_TYPE,
    modelType: 'SCORER'
  };
}

Essa configuração era consumida tanto pelo Switchboard quanto pelos clusters de serving via um sistema pub-sub (Gutenberg), permitindo ciclos de release independentes.

Os Pontos de Dor em Escala

• Ponto único de falha: Um bug ou surto de tráfego no Switchboard podia derrubar todas as experiências baseadas em ML.
• Latência adicional: 10–20ms por requisição devido a operações de serialização/desserialização, além de amplificação de latência na cauda.
• Flexibilidade reduzida do cliente: Ofuscava a visibilidade das origens das requisições, dificultando o isolamento de tenants e a separação de tráfego de teste.

A Evolução Lightbulb: Desacoplando Metadados de Roteamento do Caminho da Requisição

Em vez de abandonar o design do Switchboard, a Netflix refatorou onde e como suas responsabilidades eram executadas. A nova arquitetura, Lightbulb, separa a resolução de metadados de roteamento do encaminhamento real da requisição.

Mudanças na Arquitetura

1. Lightbulb (novo serviço): Consome um contexto mínimo da requisição (informação do caso de uso) e retorna uma routingKey e um ObjectiveConfig (ID do modelo, parâmetros de execução). Ele não está no caminho da requisição — é chamado uma vez para resolver os metadados.
2. Envoy Proxy: Lida com o roteamento real da requisição com base no cabeçalho routingKey. O Envoy já é usado para toda comunicação de saída entre apps na Netflix.
3. Enriquecimento no lado do cliente: O cliente anexa o ObjectiveConfig ao corpo da requisição (não aos cabeçalhos) para evitar inchaço.

Como o Fluxo do Plano de Dados Mudou

// Antes (Switchboard):
// Cliente -> Switchboard (desserializa, roteia, re-serializa) -> Cluster de Serving

// Depois (Lightbulb + Envoy):
// 1. Cliente chama Lightbulb (fora do caminho) para obter routingKey + ObjectiveConfig
// 2. Cliente envia requisição diretamente ao Envoy, com routingKey no cabeçalho
// 3. Envoy roteia para o VIP do cluster correto baseado na routingKey
// 4. Host de serving lê o ObjectiveConfig do corpo da requisição

Benefícios Alcançados

Limitações e Considerações

• Complexidade aumentada do cliente: Os clientes agora precisam chamar o Lightbulb primeiro, depois o Envoy. Isso adiciona um pequeno passo de coordenação, embora seja cacheado.
• Risco de deriva de configuração: Duas configurações (serving de modelo + roteamento) precisam ficar sincronizadas. O sistema Gutenberg da Netflix mitiga isso com pub-sub versionado.
• Não para todas as escalas: Se você está servindo menos de 10K requisições/segundo, um proxy centralizado como o Switchboard é mais simples e perfeitamente adequado.

Próximos Passos para Aprendizado

• Explore as capacidades de roteamento do Envoy (baseado em cabeçalho, baseado em peso, injeção de falhas) para sua própria stack.
• Estude o sistema de gerenciamento de configuração Gutenberg da Netflix para propagação dinâmica de regras.
• Considere o cache no lado do cliente de metadados de roteamento para casos de uso sensíveis à latência (a Netflix usou isso como fallback).

Para outra perspectiva sobre construção de infraestrutura resiliente e desacoplada, confira nossa análise de Por que a Airbnb Construiu Seu Próprio Mecanismo de Workflow Embutido. E para uma visão completamente diferente sobre performance de renderização, veja Estilizando Pseudo-elementos CSS Highlight.

Principais Lições para Sua Arquitetura

A jornada da Netflix do Switchboard ao Lightbulb nos ensina várias lições universais:

1. Abstraia os clientes dos detalhes internos do modelo — mas não deixe que essa abstração se torne um gargalo.
2. Separe as decisões de roteamento do encaminhamento de requisições — serviços de metadados são mais fáceis de escalar e falham independentemente.
3. Aproveite a infraestrutura existente — usar o Envoy (já presente para comunicação entre serviços) evitou introduzir uma nova dependência crítica.
4. Planeje a complexidade operacional — a arquitetura desacoplada exige mais coordenação (duas configurações, cache no cliente), mas os ganhos de confiabilidade e latência em escala valem a pena.

Se você está construindo ou evoluindo uma plataforma de serving de modelos, comece com um proxy simples, mas projete para a eventual necessidade de desacoplar. Os padrões aqui — roteamento sensível ao contexto, divisão dinâmica de tráfego e encaminhamento orientado a metadados — são diretamente aplicáveis esteja você usando Kubernetes, serverless ou bare metal.

Esta análise é baseada no post do Netflix Tech Blog "State of Routing in Model Serving" (2025).