💥 Cómo Netflix escala para gestionar más de 140.000 peticiones por segundo en menos de 3 minutos
¡Adiós picos de carga! Netflix usa multi-región, CDN y escala utilizando RPS en vez de CPU (en menos de 3 minutos) a +140k peticiones/seg. Aprende cómo.
¡Hola!
Aquí tu dosis semanal de system design y arquitectura de software.
Imagina esto: es viernes por la noche. Millones de personas en todo el planeta se relajan, eligen su próxima serie o película en Netflix y presionan "Play". Esperan una experiencia perfecta, una transmisión fluida sin interrupciones.
Lo que no saben es la cantidad de sistemas que actúan detrás de esa interfaz familiar.
Con más de 260 millones de suscriptores globales y miles de millones de horas transmitidas mensualmente, la escala de Netflix es, sencillamente, colosal. Pero el verdadero desafío no es solo el volumen diario constante.
Es lo inesperado.
Un despliegue de software que sale mal. Un evento externo como el final de un partido de fútbol o el estreno mundial de una serie como "El Juego del Calamar".
De repente, en cuestión de minutos, ¡a veces segundos!, el tráfico dirigido a ciertas partes de la infraestructura de Netflix puede multiplicarse por dos (en un failover) o incluso por cien (al restaurar una región). Una auténtica avalancha digital.
Para los ingenieros de Netflix, esto no es una hipótesis, es una realidad operativa.
El reto no es solo cuestión de números, sino de experiencia de usuario: ¿Cómo absorbes picos de carga tan masivos y repentinos sin que ni uno de esos millones de usuarios note la más mínima degradación en su maratón de fin de semana?
Mantener la promesa de una experiencia impecable frente a esta volatilidad extrema requirió que Netflix fuera más allá de las prácticas estándar. Tuvieron que innovar y construir un sistema de resiliencia de clase mundial para domar estas tormentas de tráfico.
🌋 El Desafío: Picos Repentinos en un Mundo Distribuido
Netflix ya operaba sobre una base sólida: una vasta infraestructura activa-activa en AWS (principalmente en us-east-1, us-east-2, us-west-2, eu-west-1) y una compleja arquitectura de miles de microservicios desacoplados, a menudo gestionados por su plataforma de contenedores Titus. Esto les daba flexibilidad y escalabilidad, pero también presentaba problemas ante picos súbitos:
Efecto cascada: Aunque los microservicios están desacoplados (muchos usan colas SQS/Kinesis), un pico de tráfico en una región o servicio podía amplificarse rápidamente al propagarse por la red de microservicios dependientes. Por eso es una buena práctica evitar retries fijos en tus llamadas entre servicios. En lugar de ello, utiliza algoritmos como token bucket
Autoscaling tradicional lento: Escalar basado solo en métricas estándar como el uso de CPU (con métricas de CloudWatch de 1 minuto) era demasiado lento. La detección tardaba (~4 min) y el arranque de instancias (~6 min) llevaba a un Time-to-Recovery (TTR) de unos 20 minutos, inaceptable para picos rápidos. En un sistema como Netflix, esto es una eternidad
Visibilidad limitada: Entender la capacidad real y los umbrales de fallo de cada microservicio bajo estrés extremo era complejo al no tneer métricas adecuadas y pruebas constantes.
Necesitaban una forma más rápida, inteligente y resistente de capear estas tormentas de tráfico
.
💡 La Transición: Hacia la Resiliencia Reactiva
Por eso, el equipo de ingeniería de Netflix se centró en mejorar drásticamente cómo anticipaban y reaccionaban a estos picos.
El objetivo: reducir el tiempo de recuperación y proteger la experiencia del usuario a toda costa.
Como detallaron en AWS re:Invent, desarrollaron un conjunto de estrategias específicas combinando planificación inteligente con reacciones ultrarrápidas.
Vamos a ello.
🗺️ Estrategias Generales para Gestionar la Carga
Antes de ver la solución específica de Netflix, recordemos algunos enfoques generales para manejar la carga en sistemas distribuidos:
Escalado Proactivo (Predictive Scaling): Aumentar la capacidad antes de que llegue el pico esperado (ej. lanzamiento de una serie).
Escalado Reactivo (Reactive Scaling): Aumentar la capacidad en respuesta a un aumento detectado en la carga.
Limitación / Degradación Controlada (Load Shedding): Rechazar selectivamente peticiones menos críticas para proteger los servicios esenciales cuando el sistema está sobrecargado.
Distribución de Carga (Traffic Shaping / Steering): Dirigir el tráfico geográficamente para balancear la carga entre diferentes centros de datos o regiones.
▶️ El Enfoque Concreto de Netflix: Una Combinación Inteligente
Netflix no se decanta por una única solución, sino que utiliza una combinación de todas estas estrategias, orquestadas sobre su infraestructura cloud activa-activa en AWS.
Piensa en ello como un sistema de gestión de emergencias urbanas: tienen predicciones de tráfico (prescaling), desvíos planificados (traffic shaping), pero también equipos de respuesta ultrarápida (autoscaling por RPS - Requests Per Second) y protocolos para priorizar vehículos de emergencia (load shedding) cuando ocurre un accidente imprevisto.
🔩 Deep Dive por Componentes Clave
Cuando el pico es inesperado, estas piezas entran en juego:
#1 ☁️ Infraestructura Multi-Región en AWS
¿Para qué sirve? Proporciona la base de escalabilidad global, redundancia y distribución geográfica de la carga.
Cómo funciona:
Netflix despliega sus servicios en múltiples regiones de AWS (como us-east-1, us-west-2, eu-west-1).
El tráfico de los usuarios se dirige a la región más cercana o más saludable a través de servidores DNS inteligentes.
Si una región falla o se sobrecarga, el tráfico puede ser desviado a otras regiones "salvadoras" (failover). Ten en cuenta que esto puede ser un pico de carga hasta 2x para la nueva región.
Tecnologías clave: AWS (EC2, VPC, ELB/ALB, ASG, S3), Titus (gestión de contenedores), DNS inteligente.
Piensa en esto como una cadena de supermercados que tiene varios en la misma ciudad. Las personas van al supermercado más cercano a su casa. Si uno de los supermercados tiene que cerrar de imprevisto o tiene largas colas, los clientes van a otro en la misma ciudad. En este caso, son las peticiones las que van a los centros de datos distribuidos geográficamente
#2 🌍 Open Connect (CDN Propia)
¿Para qué sirve? Acerca el contenido de vídeo (¡el 100%!) a los usuarios finales, reduciendo drásticamente la latencia y, absorbiendo gran parte de la carga de streaming antes de que llegue a los microservicios centrales.
Cómo funciona:
Netflix despliega miles de servidores llamados Open Connect Appliances (OCAs) dentro de las redes de los proveedores de internet (ISPs) y en puntos de intercambio de internet (IXPs).
Predicen qué contenido será popular en cada zona y lo copian (cachean) en los OCAs locales durante las horas de baja demanda.
Cuando un usuario reproduce un vídeo, se sirve desde el OCA más cercano, no desde los servidores centrales de Netflix.
Tecnologías clave: Hardware/Software OCA custom, BGP, Zuul (Netflix Edge Gateway).
Imagínalo como tener quioscos en cada barrio con las revistas más vendidas ya impresas. La mayoría compra allí, evitando que la imprenta central se sature.
#3 🚀 Autoscaling Rápido Basado en RPS
¿Para qué sirve? Escalar la capacidad de los microservicios de forma casi instantánea cuando detecta un pico súbito de peticiones, superando la lentitud del escalado tradicional basado en CPU.
Cómo funciona:
Monitorizan las Requests Per Second (RPS) con alta resolución (métrica de 5 segundos de Atlas, su sistema interno, en lugar de 1 minuto que tenían anteriormente en AWS CloudWatch). En lugar de esperar a que la CPU se sature (lo cual ocurre tarde, durante el load shedding), escalan antes. Piensa que durante el load shedding, los servicios siguen reciviendo las peticiones y las descartan, por lo que no tienen un coste cero como si la petición nunca hubiera existido.
Al detectar un pico rápido de RPS que supera un umbral, activan una política de escalado "Hammer". Esta política intenta añadir toda la capacidad necesaria de golpe ("one shot to success"), en lugar de añadir instancias poco a poco.
Arranque Optimizado: Han optimizado el tiempo de arranque de instancias y aplicaciones (ej. arranque en paralelo), reduciendo el tiempo de boot de ~6 min a ~2 min. Resultado: El TTR para un pico >2x se reduce de ~20 min a ~3 minutos (~1 min detección + ~2 min boot).
Tecnologías clave: Lógica de autoscaling personalizada, sistema de métricas interno (Atlas), AWS EC2 y Auto-Scaling Groups.
Seguro que has jugado alguna vez a videjuegos como Need For Speed. Imagínate que en lugar de acelerar gradualmente un coche e ir aumentando de marcha una a una, pisas a fondo un botón de "nitro" para alcanzar la velocidad necesaria instantáneamente, aunque consumas más combustible en ese momento.
#4 🚦 Microservice Buffers y Load Shedding Priorizado
¿Para qué sirve? Permitir que cada microservicio absorba picos moderados sin errores y, en casos extremos, degradar el servicio de forma controlada (load shedding) para proteger las funciones críticas y evitar el colapso total.
Cómo funciona:
Buffers de Capacidad: Cada servicio se ejecuta con margen. Tiene un "Success Buffer" (puede absorber picos razonables, ~2x, sin errores) y un "Failure Buffer" (puede absorber picos catastróficos antes de empezar a fallar o descartar peticiones).
Clasificación de Criticidad: Peticiones y servicios se etiquetan por Tier/importancia.
Shedding Priorizado: Si la carga supera el Success Buffer y amenaza el Failure Buffer, se empiezan a descartar peticiones de baja prioridad (tareas de fondo, API no esenciales). Si la presión continúa, se descartan peticiones más importantes, siempre intentando preservar el core (ej. reproducción).
Retries Inteligentes: Usan backoff exponencial con full jitter específicamente en escenarios de shedding para evitar tormentas de reintentos.
Tecnologías clave: Lógica de priorización en servicios, API Gateway (Zuul), configuración de umbrales, algoritmos de backoff/jitter.
Como los controladores aéreos en una tormenta: primero retrasan vuelos menos críticos, luego desvían algunos, pero hacen todo lo posible por mantener los aterrizajes y despegues esenciales seguros
#5 🏋️ Pruebas de Resiliencia Continuas (Chaos Engineering)
¿Para qué sirve? Validar proactivamente que todas estas estrategias funcionan juntas como se espera en producción o entornos idénticos, inyectando fallos y picos de carga controlados.* Cómo funciona:
Usan su "Chaos Automation Platform" y una pirámide de pruebas:
Pruebas sintéticas a nivel de servicio: Hacen stress tests a servicios individuales aisladamente.
Pruebas de carga en producción: Inyectar carga controlada en el entorno real (load test).
Pruebas de escalado regional: Simular el escalado masivo de una región entera.
Pruebas de carga regional: Simular un pico de tráfico masivo dirigido a una sola región.
Incluyen la simulación de failovers regionales como parte de las pruebas, ya que son una fuente real de picos.
Tecnologías clave: Plataformas de Chaos Engineering, herramientas de inyección de carga, Chaos Monkey.
Son los simulacros de incendio, pruebas de estrés de puentes y crash tests de coches del mundo del software: pruebas destructivas para garantizar la seguridad y resistencia.
📝 Recapitulación de la Arquitectura de Resiliencia
En resumen, la estrategia de Netflix para domar los picos de tráfico se basa en:
Base sólida: Infraestructura multi-región activa-activa en AWS y miles de microservicios desacoplados con buffers.
Reducción de carga base: Open Connect CDN y caching multinivel absorben gran parte de la demanda.
Anticipación Proactiva: Prescaling y Traffic Shaping para eventos conocidos o geográficamente localizados.
Desubrieron que escalar por CPU no les servía: Aunque hagan load-shedding, la CPU no baja porque siguen llegando el mismo número de peticiones.
Monitorización Clave: Métricas de RPS de alta resolución (Atlas, 5s) para detección temprana.
Reacción Ultrar-rápida: Autoscaling "Hammer" basado en RPS para escalar masivamente en ~3 minutos.
Protección bajo presión: Load shedding priorizado para descartar tráfico no esencial y proteger el core.
Validación Constante: Pruebas de resiliencia rigurosas y Chaos Engineering.
👋 ¿Quieres Dominar el System Design?
Entender cómo empresas como Netflix construyen sistemas robustos a escala es vital para una entrevista de system design.
¡Hasta la próxima semana!
🗞️ Referencias:
Charla AWS re:Invent 2024: NFX301: How Netflix handles sudden load spikes in the cloud (Slides: https://reinvent.awsevents.com/content/dam/reinvent/2024/slides/nfx/NFX301_How-Netflix-handles-sudden-load-spikes-in-the-cloud.pdf, Vídeo)
Netflix en AWS: Casos de estudio e historias (https://aws.amazon.com/solutions/case-studies/innovators/netflix/)
Netflix Open Connect: Visión general (https://openconnect.netflix.com)
Estadísticas de Netflix: Search Logistics (https://www.searchlogistics.com/learn/statistics/netflix-statistics/)
Blog Post Análisis: How Netflix Handles Sudden Load Spikes in the Cloud? (What I Learned) - Ujjawal Poudel, Medium (https://medium.com/@ujjawalpoudel/how-netflix-handles-sudden-load-spikes-in-the-cloud-what-i-learned-f058a4d80af3)
📝 Otros artículos de interés
![👨💻[INFOGRAPHIC] The 10 times in history that software engineers were to be replaced](https://substackcdn.com/image/fetch/w_140,h_140,c_fill,f_webp,q_auto:good,fl_progressive:steep,g_auto/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F9e6c5116-8d2a-478a-a0cb-01ecbeae119c_800x2000.jpeg)
👏 Aplauso semanal
Aquí algunos artículos que me han gustado esta última semana:
Carta para el síndrome del impostor de
. Aprender a no arreglarlo todo y a 'soltar' es una habilidad crucial para los desarrolladores, más allá de la pura técnica.Skill Stacking para managers de
. Ser 'moderadamente bueno' en varias habilidades complementarias y combinarlas crea un perfil profesional más único y valioso que la especialización extrema. Puedes crear una combinación única.De 25 minutos a 16 segundos: nueva capacidad de Docker Server en AWS CodeBuild de
La nueva función Docker Server de AWS CodeBuild puede reducir drásticamente los tiempos de construcción de imágenes Docker, usando una caché de capas persistente y centralizada.
🙏 Una última cosa antes de que te vayas:
Siempre estoy trabajando para hacer esta newsletter aún mejor.
¿Podrías tomarte un minuto para responder una encuesta rápida y anónima?
Nos vemos en el próximo correo,
Fran.
A quién no le gustaría estar viendo en los HQ de Netflix viendo como escalan servidores con cuentas bancarias infinitas :) Excelente repaso, gracias por la mención ;)