Netflix, como hyperscaler, enfrenta picos de tráfico impredecibles que pueden exceder la capacidad provisionada, llevando a congestive failures y cascading failures si no se gestionan adecuadamente. La estrategia inicial de scaling (proactivo y reactivo) es insuficiente debido a la latencia del scaling reactivo y el costo/limitaciones de capacidad del scaling proactivo. Sin load shedding, los servidores pueden agotarse, fallar sus health checks y desencadenar una reacción en cadena donde la falla de una instancia sobrecarga a las demás, antes de que el autoscaling pueda responder.
La solución clave es el 'Prioritized Load Shedding', que reconoce que no todas las solicitudes tienen el mismo valor. Al clasificar las solicitudes por prioridad (ej. user-initiated vs. prefetch), el sistema puede desechar selectivamente el tráfico de baja prioridad para proteger la disponibilidad de las solicitudes críticas. Esto se implementa a nivel de servicio, a través de un sidecar Envoy Proxy, que utiliza métricas de utilización (CPU, latencia) y la prioridad de la solicitud para tomar decisiones de shedding. La visibilidad de la utilización del servicio como 'leading indicator' es crucial, a diferencia de las tasas de error que son 'lagging indicators'.
Las salvaguardas fallaron inicialmente porque el load shedding se implementó en el API Gateway, que carecía de visibilidad granular de la utilización del servicio y no cubría el tráfico backend-to-backend. La migración a un enfoque a nivel de servicio, con la propagación de prioridades a través de headers y la comunicación de carga mediante ORCA, permitió una toma de decisiones más precisa y una protección efectiva. Además, la introducción de 'Prioritized Backoff' y 'Prioritized Attempt Budget' a nivel de cliente aborda el problema de los retry storms, que pueden exacerbar la sobrecarga del servidor, asegurando que los reintentos también respeten las prioridades de las solicitudes.