Shedding, también conocido como 'Load Shedding' o 'Traffic Shedding', es una estrategia de resiliencia en sistemas distribuidos diseñada para prevenir el colapso catastrófico bajo condiciones de sobrecarga extrema. En lugar de intentar procesar todas las solicitudes entrantes y arriesgarse a que todos los servicios se degraden o fallen, un sistema que implementa shedding decide proactivamente rechazar, retrasar o degradar una porción del trabajo. El objetivo principal es mantener la funcionalidad básica y la estabilidad de los servicios críticos, incluso si esto significa sacrificar la disponibilidad o la calidad de servicio para una parte de los usuarios o solicitudes. Las decisiones de shedding pueden basarse en métricas como la latencia del servicio, la utilización de CPU/memoria, el tamaño de las colas de trabajo o la prioridad de las solicitudes.
En el mundo real, el shedding se implementa en una variedad de sistemas de alto rendimiento y gran escala. Por ejemplo, Netflix utiliza técnicas de shedding en su infraestructura para proteger sus servicios de streaming durante picos de tráfico inesperados, priorizando la reproducción de video sobre otras funciones menos críticas. Los balanceadores de carga modernos, como NGINX o HAProxy, pueden configurarse para realizar shedding al rechazar conexiones cuando los servidores backend están sobrecargados. Las bases de datos distribuidas y los sistemas de mensajería (ej., Apache Kafka) pueden implementar shedding al limitar la tasa de escritura o lectura, o al descartar mensajes de baja prioridad para proteger la integridad del clúster. Los sistemas de control de admisión en microservicios también pueden aplicar shedding para evitar que un servicio sobrecargado afecte a toda la cadena de llamadas.
Para un Arquitecto de Sistemas, comprender y aplicar el shedding es crucial para diseñar sistemas robustos y resilientes. Permite tomar decisiones estratégicas sobre cómo el sistema debe fallar 'graciosamente' en lugar de colapsar por completo. Los trade-offs incluyen la elección de qué tráfico o trabajo descartar (ej., solicitudes de baja prioridad, usuarios no premium, tráfico de bots), cómo comunicar esta decisión al cliente (ej., HTTP 503 Service Unavailable, degradación silenciosa) y cómo monitorear el impacto del shedding. Un arquitecto debe considerar la implementación de mecanismos de shedding en puntos clave de la arquitectura (ej., API Gateways, balanceadores de carga, servicios individuales) y definir políticas claras que equilibren la disponibilidad con la estabilidad, asegurando que los servicios más críticos permanezcan operativos incluso bajo estrés extremo.