Cómo Netflix Enruta 1 Millón de Peticiones de ML por Segundo de Switchboard a Lightbulb

Por Qué el Enrutamiento es Clave en el Serving de ML

Cuando estás sirviendo cientos de tipos y versiones de modelos a más de 1 millón de peticiones por segundo, la forma en que enrutas el tráfico a la instancia correcta se convierte en una decisión arquitectónica crítica. La plataforma de serving de ML de Netflix impulsa experiencias personalizadas en recomendaciones de títulos, comercio y detección de fraudes. El desafío central: ¿cómo enrutar el tráfico al modelo correcto, en el shard de clúster correcto, para el usuario y caso de uso correctos — manteniendo la abstracción de la API simple tanto para los servicios cliente como para los investigadores?

Este post (primero de una serie del blog técnico de Netflix) desglosa la evolución de su capa de enrutamiento: desde un proxy centralizado llamado Switchboard hasta un enfoque desacoplado y basado en metadatos llamado Lightbulb. Es una clase magistral sobre cómo equilibrar la abstracción con la realidad operativa a hiperescala.

Por qué esto importa para tu arquitectura: Si estás construyendo cualquier infraestructura de serving de modelos — ya sea para recomendaciones, detección de fraudes o IA generativa — los patrones de enrutamiento descritos aquí impactan directamente tu latencia, confiabilidad y velocidad de iteración. Los tradeoffs que Netflix encontró son universales.

Fuente: Netflix Tech Blog

El Diseño Original: Switchboard como Proxy Central de Enrutamiento

El primer enfoque de Netflix fue Switchboard, un servicio personalizado que actuaba como punto único de entrada para todas las peticiones de inferencia de modelos. Se situaba directamente en la ruta de la petición, realizando enrutamiento consciente del contexto y enriquecimiento de la petición.

Capacidades Clave

• Abstracción Común para Clientes: Los clientes solo necesitaban integrarse una vez. Después de eso, las iteraciones de modelo, experimentos A/B y migraciones de shard eran opacas para ellos.
• Enrutamiento Consciente del Contexto: Switchboard podía enrutar basándose en el dispositivo del usuario, ubicación, superficie de ranking (homepage vs. búsqueda) o asignación de test A/B.
• División Dinámica de Tráfico: Deployments canary y lanzamientos graduales en tiempo real.
• Versionado y Ciclo de Vida de Modelos: Pruebas en modo shadow, rollbacks instantáneos.

El Pegamento: Reglas de Switchboard

Los investigadores definían la lógica de enrutamiento mediante una configuración JavaScript:

/**
 * Regla de configuración escrita por un Investigador de Modelos para agregar un experimento A/B.
 * Celda 1: Usa el modelo predeterminado, actualmente en producción
 * Celda 2 y Celda 3: Usan diferentes modelos experimentales (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'
  };
}

Esta configuración era consumida tanto por Switchboard como por los clústeres de serving a través de un sistema pub-sub (Gutenberg), permitiendo ciclos de release independientes.

Los Puntos de Dolor a Escala

• Punto único de fallo: Un bug o un aumento de tráfico en Switchboard podía tirar todas las experiencias basadas en ML.
• Latencia adicional: 10–20ms por petición debido a operaciones de serialización/deserialización, más amplificación de latencia en la cola.
• Flexibilidad reducida del cliente: Ocultaba la visibilidad de los orígenes de las peticiones, dificultando el aislamiento de tenants y la separación del tráfico de prueba.

La Evolución Lightbulb: Desacoplando Metadatos de Enrutamiento de la Ruta de la Petición

En lugar de abandonar el diseño de Switchboard, Netflix refactorizó dónde y cómo se ejecutaban sus responsabilidades. La nueva arquitectura, Lightbulb, separa la resolución de metadatos de enrutamiento del reenvío real de la petición.

Cambios en la Arquitectura

1. Lightbulb (nuevo servicio): Consume un contexto mínimo de la petición (información del caso de uso) y devuelve una routingKey y un ObjectiveConfig (ID del modelo, parámetros de ejecución). No está en la ruta de la petición — se llama una vez para resolver los metadatos.
2. Envoy Proxy: Maneja el enrutamiento real de la petición basado en el encabezado routingKey. Envoy ya se usa para toda la comunicación de salida entre aplicaciones en Netflix.
3. Enriquecimiento del lado del cliente: El cliente adjunta el ObjectiveConfig al cuerpo de la petición (no a los encabezados) para evitar inflado.

Cómo Cambió el Flujo del Plano de Datos

// Antes (Switchboard):
// Cliente -> Switchboard (deserializa, enruta, re-serializa) -> Clúster de Serving

// Después (Lightbulb + Envoy):
// 1. Cliente llama a Lightbulb (fuera de la ruta) para obtener routingKey + ObjectiveConfig
// 2. Cliente envía petición directamente a Envoy, con routingKey en el encabezado
// 3. Envoy enruta al VIP del clúster correcto basado en la routingKey
// 4. Host de serving lee el ObjectiveConfig del cuerpo de la petición

Beneficios Obtenidos

Limitaciones y Consideraciones

• Complejidad aumentada del cliente: Los clientes ahora necesitan llamar a Lightbulb primero, luego a Envoy. Esto agrega un pequeño paso de coordinación, aunque se almacena en caché.
• Riesgo de desviación de configuración: Dos configuraciones (serving de modelo + enrutamiento) deben mantenerse sincronizadas. El sistema Gutenberg de Netflix mitiga esto con pub-sub versionado.
• No para todas las escalas: Si estás sirviendo menos de 10K peticiones/segundo, un proxy centralizado como Switchboard es más simple y perfectamente adecuado.

Próximos Pasos para Aprender

• Explora las capacidades de enrutamiento de Envoy (basado en encabezado, basado en peso, inyección de fallos) para tu propio stack.
• Estudia el sistema de gestión de configuración Gutenberg de Netflix para propagación dinámica de reglas.
• Considera el caché del lado del cliente de metadatos de enrutamiento para casos de uso sensibles a la latencia (Netflix lo usó como fallback).

Para otra perspectiva sobre la construcción de infraestructura resiliente y desacoplada, echa un vistazo a nuestro análisis de Por Qué Airbnb Construyó Su Propio Motor de Workflow Embutido. Y para una visión completamente diferente sobre el rendimiento de renderizado, mira Estilizando Pseudo-elementos CSS Highlight.

Conclusiones Clave para Tu Arquitectura

El viaje de Netflix de Switchboard a Lightbulb nos enseña varias lecciones universales:

1. Abstract a los clientes de los detalles internos del modelo — pero no dejes que esa abstracción se convierta en un cuello de botella.
2. Separa las decisiones de enrutamiento del reenvío de peticiones — los servicios de metadatos son más fáciles de escalar y fallan de forma independiente.
3. Aprovecha la infraestructura existente — usar Envoy (ya presente para la comunicación entre servicios) evitó introducir una nueva dependencia crítica.
4. Planifica la complejidad operativa — la arquitectura desacoplada requiere más coordinación (dos configuraciones, caché del cliente), pero las ganancias de confiabilidad y latencia a escala valen la pena.

Si estás construyendo o evolucionando una plataforma de serving de modelos, comienza con un proxy simple, pero diseña para la eventual necesidad de desacoplar. Los patrones aquí — enrutamiento consciente del contexto, división dinámica de tráfico y reenvío basado en metadatos — son directamente aplicables ya sea que uses Kubernetes, serverless o bare metal.

Este análisis se basa en el post del Netflix Tech Blog "State of Routing in Model Serving" (2025).