Load Shedding

Qué es

Load Shedding elimina, rechaza o deja de iniciar deliberadamente cierto trabajo para preservar la salud del sistema y la capacidad destinada a trabajo de mayor valor. Explicita un sacrificio: parte de la demanda no recibirá el servicio normal. Su corrección depende de qué se sacrifica, cuándo se hace y qué obligación existía antes de decidirlo.

overload or credible risk of overload
    -> reject / remove eligible lower-value work
    -> preserve critical capacity and useful progress

Puede activarse antes del colapso, cuando aparecen señales de saturación. Esperar a que todos los workers estén bloqueados reduce la capacidad de rechazar limpiamente. La decisión debe ahorrar el recurso escaso; cancelar una consulta costosa después de completarla solo cambia la respuesta, no recupera el esfuerzo.

Qué preservar y qué sacrificar

El criterio puede incluir prioridad, costo, vigencia y dependencia de negocio. Una actualización opcional de recomendaciones no tiene la misma obligación que registrar un cobro confirmado. El valor debe definirse con responsables del dominio; una etiqueta «no crítico» asignada únicamente para reducir métricas de error puede ocultar un incumplimiento real.

Google SRE describe degradación de respuestas y prioridades de tráfico como formas de sostener servicio bajo restricciones. El ejemplo sirve para distinguir una respuesta parcial válida de un fallo presentado como éxito. Handling Overload.

Una petición stale ya no tiene utilidad dentro de su contrato. Expirarla puede ahorrar procesamiento, pero vencer el plazo de una respuesta HTTP no vuelve innecesaria una obligación durable. Un pago aceptado puede requerir terminar o reconciliarse aunque el usuario haya cerrado la página. deadline delimita tiempo disponible; el dominio determina qué intención sigue vigente.

Rechazo explícito y obligaciones durables

Load Shedding no equivale a pérdida silenciosa de datos. Rechazar antes de aceptar debe comunicar que el trabajo no fue asumido. Si ya existe una obligación persistente, borrarla para aliviar backlog exige una condición válida de negocio y una resolución observable, o una transferencia durable de responsabilidad.

Para un mensaje que debe procesarse, puede pausarse consumo, diferirse ejecución o trasladarse a recuperación bajo un contrato claro. Una dead-letter-queue no completa automáticamente la intención ni debe convertirse en un basurero genérico para demanda excesiva. Confirmar un ack y olvidar el mensaje sin resolver el efecto rompería la garantía, aunque mejorara la latencia del consumidor.

Distinguir tres resultados evita ambigüedad: no aceptado, aceptado pero pendiente y terminado mediante una alternativa permitida. Un fallo después de un efecto irreversible requiere consultar o reconciliar; no corresponde responder «rechazado sin efecto» si ese estado no está demostrado.

Prioridad y fairness

Una política puede rechazar primero trabajo opcional, limitar categorías costosas o repartir una fracción de rechazos entre tenants. Prioridad y fairness no son equivalentes: prioridad protege valor relativo; fairness define cómo repartir oportunidades y sacrificios. Una prioridad absoluta puede dejar una categoría sin progreso durante un incidente largo.

También puede ser necesario reservar capacidad para recuperar el sistema: operaciones de reconciliación, control o diagnóstico no deberían competir sin protección con toda la demanda ofrecida. bulkhead puede aislar esa capacidad. La reserva tiene costo y debe probarse contra recursos compartidos que escapan de la partición.

Evitar que cualquier cliente declare arbitrariamente su propia prioridad máxima. Una política de negocio puede precisar autenticación de la identidad o de la clase de servicio, sin convertir el mecanismo de shedding en una solución general de seguridad.

Fronteras conceptuales

admission-control responde si se acepta nuevo trabajo; Load Shedding enfatiza sacrificar trabajo para preservar salud. Un rechazo en admisión puede cumplir ambas funciones. La literatura usa límites distintos y no existe una separación universal que reserve shedding únicamente a trabajo ya aceptado.

rate-limiting puede rechazar porque se excedió una cuota aunque haya recursos disponibles. Shedding puede reaccionar a capacidad deteriorada aun cuando nadie excedió cuota. backpressure busca que upstream reduzca producción; shedding define qué hacer cuando la demanda no puede mantenerse. Un rechazo solo produce backpressure si alguien interpreta la señal y cambia el flujo.

fallback ofrece un resultado alternativo bajo un contrato explícito. Puede apoyar degradación parcial, pero no es obligatorio ni gratuito: llamar a otra dependencia sobrecargada puede desplazar el problema. No se debe omitir un cobro obligatorio y presentar el pedido como pagado.

Ejemplo transversal

En API Gateway → Order → Payment, el tráfico pasa de 100 a 300 req/s y la capacidad útil ronda 120. Una política ilustrativa puede rechazar nuevas recomendaciones de compra o desactivar enriquecimiento opcional antes de consumir Payment, preservando los pedidos que sí pueden completarse.

Los números no indican exactamente cuántas solicitudes sacrificar: unas operaciones cuestan más que otras y las ya aceptadas siguen consumiendo capacidad. Si toda la demanda es crítica, no existe trabajo opcional mágico; se necesitará rechazo explícito, espera válida o capacidad adicional. Declarar todo crítico tampoco elimina los límites físicos.

Reintentar de inmediato cada rechazo puede deshacer el ahorro. retry debe respetar elegibilidad y presupuestos; backoff y jitter espacian tentativas sin prometer que el servicio podrá asumirlas. El cliente necesita distinguir límite de política, fallo persistente y saturación temporal.

Recuperación, observación y uso

Observar quién fue rechazado, por qué, cuánto recurso se ahorró y qué trabajo aceptado completó dentro del objetivo. AWS destaca que mezclar latencias de rechazos rápidos con solicitudes atendidas puede ocultar deterioro del servicio real. Using load shedding to avoid overload.

Usarlo cuando existan sacrificios permitidos y verificables frente a overload. No usarlo para encubrir pérdida durable, capacidad permanentemente insuficiente o políticas que nadie acordó. Umbrales demasiado bajos rechazan trabajo atendible; decisiones tardías gastan recursos antes de protegerlos.

La recuperación debe liberar admisión progresivamente y observar backlog y presión, en lugar de desactivar todo límite al primer indicador favorable. Puede ayudar a romper el feedback de metastable-failures, pero retirar protección simultáneamente para muchos clientes puede causar thundering-herd y otra sobrecarga. Probar aceptación, rechazo, degradación y recuperación juntos permite comprobar que el servicio conserva trabajo útil y comunica fielmente lo que dejó de hacer.