O time de engenharia da Netflix publicou em maio de 2026 um post tecnico que mergulha em como a empresa organiza o roteamento dentro da sua plataforma central de servico de modelos de machine learning. Faz parte de uma serie multi-parte sobre a arquitetura, e este capitulo se concentra na camada que decide para onde cada requisicao de inferencia deve ir, dentro de uma plataforma que serve centenas de tipos e versoes de modelo, com pico ao redor de 1 milhao de requisicoes por segundo.

O que e model serving

A expressao “model serving” descreve a parte do ciclo de vida de um modelo de machine learning que vem depois do treino: receber uma requisicao em producao, aplicar o modelo treinado sobre o input e devolver uma previsao em latencia compativel com o produto. Sao operacoes diferentes do treino, que e batch, demorado e roda em ambiente separado.

Um modelo de recomendacao que precisa responder em 50 milissegundos para personalizar a tela inicial de um usuario tem requisitos muito distintos de um modelo de previsao de demanda que roda uma vez por hora. Por isso, model serving costuma ter sua propria infraestrutura, com servidores otimizados para inferencia, gerencia de versoes ativas e mecanismos de fallback caso um modelo retorne erro.

A escolha da Netflix por uma plataforma central

A Netflix nao deixou cada time montar sua infraestrutura propria de serving. A empresa centralizou essa funcao numa plataforma unica que e consumida por dezenas de microservicos especificos de dominio. Recomendacao, busca, qualidade de encoding, deteccao de fraude, personalizacao de thumbnails: todos esses dominios consomem a mesma plataforma central, com APIs padronizadas.

A aposta por trabalhar com plataforma unica e classica em empresas grandes. Permite consolidar investimento em desempenho, observabilidade, seguranca e padroes operacionais num lugar so. O custo dessa escolha e que a plataforma precisa lidar com requisitos heterogeneos: latencia, tipos de input, formato de output, modelo de cobranca interna entre times.

Numeros que importam

Dois numeros do post chamam atencao. O primeiro: centenas de tipos e versoes de modelo rodando em producao em paralelo. Isso ja exige um sistema de gerencia de catalogo bem amarrado, com versionamento, rollout gradual e capacidade de rollback rapido.

O segundo: pico de aproximadamente 1 milhao de requisicoes por segundo. Em escala desse tamanho, decisoes triviais como o tipo de balanceamento de carga ou o protocolo de transporte deixam de ser detalhes e passam a definir custo e disponibilidade. A camada de roteamento e exatamente onde essas decisoes vivem.

Por que uma camada de roteamento dedicada

A pergunta natural e: por que nao deixar cada microservico chamar o modelo dele direto, sem uma camada extra? A resposta que a Netflix da no post envolve tres motivos.

Primeiro, abstracao. Uma API uniforme deixa o microservico de recomendacao indiferente a se o modelo dele e um TensorFlow rodando em GPU ou um modelo mais leve em CPU. A camada de roteamento esconde essa heterogeneidade.

Segundo, controle operacional. Concentrar o trafego num gateway facilita aplicar limites de taxa, cotas por time, monitoria centralizada e politicas de retry. Sem isso, cada equipe precisaria reimplementar essas funcoes.

Terceiro, evolucao. Quando o time quer trocar a tecnologia por tras de um modelo (migrar de um framework para outro, mudar de GPU pra CPU), basta atualizar o roteamento. O codigo do microservico continua igual.

Trade-offs sinalizados

O post sinaliza um trade-off importante sobre abstracao de API. Quando a plataforma cria uma camada generica que serve a todos os dominios, ela precisa decidir o quanto expoe das particularidades de cada modelo. Uma API generica demais limita o que microservicos especializados conseguem fazer. Uma API muito proxima do modelo cobra esforco extra dos consumidores.

A Netflix descreve esse equilibrio como um trabalho continuo. A serie da blog vai ao longo de varios posts justamente para mostrar como a empresa lida com essas escolhas em cada camada. Nao e um problema com resposta unica.

Por que tecnologos brasileiros em MLOps devem ler

MLOps (operacao de machine learning em producao) ainda e disciplina jovem em muitos times brasileiros. Posts como esse, com dados reais e arquitetura aberta, sao referencia rara. Times que estao construindo plataformas internas de serving podem comparar suas escolhas com as decisoes da Netflix e entender quais trade-offs ja foram batidos por uma empresa em escala alta.

O recado mais util para o publico daqui talvez nao seja copiar a arquitetura, mas absorver a logica: comece simples, padronize cedo, instrumente desde o dia um. Sem esses tres movimentos, a plataforma cresce sem visibilidade e o custo aparece tarde demais para corrigir.

Reportado originalmente por Netflix Tech Blog em maio de 2026.