Overload

Qué es

Overload ocurre cuando la demanda efectiva excede durante suficiente tiempo la capacidad que un sistema puede atender manteniendo sus objetivos. La capacidad depende del trabajo, los recursos disponibles y las dependencias: no es una cifra inmutable de requests por segundo. Un servicio puede perder capacidad sin recibir más solicitudes, por ejemplo cuando sus llamadas remotas retienen conexiones durante más tiempo.

Alta utilización no equivale a overload. Un worker que procesa un lote al 95 % de CPU, con memoria estable y terminación dentro del plazo, puede estar funcionando como se espera. Hay overload cuando el trabajo ofrecido desborda las condiciones sostenibles de servicio: crece la espera, se agotan recursos, se incumplen objetivos o disminuye el trabajo útil completado.

Llegadas, servicio y saturación

Arrival rate describe el ritmo de llegada a una frontera concreta. Service rate describe el ritmo al que esa etapa completa trabajo bajo unas condiciones determinadas. Compararlas exige unidades compatibles: mensajes pequeños y operaciones costosas no representan la misma demanda. También importa la distribución temporal; un promedio por minuto puede ocultar segundos que desbordan una cola.

Saturación significa que un recurso alcanza su límite operativo. Puede tratarse de workers, conexiones, CPU, memoria, disco o permisos hacia una dependencia. Contention añade competencia por recursos compartidos: más trabajo concurrente puede producir más espera por locks, coordinación o cambios de contexto, sin aumentar proporcionalmente las finalizaciones.

No todo recurso saturado causa inmediatamente un fallo de objetivos. Una etapa puede absorber un burst dentro del margen previsto. Tampoco una CPU relativamente libre descarta overload: veinte conexiones ocupadas por llamadas lentas pueden bloquear una operación cuya CPU local apenas se utiliza. El diagnóstico debe seguir el cuello de botella y el recurso retenido.

Colas y degradación

Cuando llegan tareas más rápido de lo que se completan, el excedente necesita esperar, rechazarse o reducirse. queue-management permite decidir cuánto puede esperar y con qué política. Una cola añade espacio para absorber variación; no crea capacidad de procesamiento. Memoria finita, límites del broker o deadlines terminan imponiendo una frontera.

Una cola creciente eleva la latencia antes de empezar el trabajo. Solicitudes que ya dejaron de ser útiles pueden competir con otras todavía vigentes. Google SRE describe cómo las colas largas y las solicitudes que superan sus deadlines desperdician recursos y favorecen fallos en cadena. Addressing Cascading Failures.

Conviene separar trabajo ofrecido, aceptado y completado útilmente. Un contador elevado de operaciones iniciadas no demuestra progreso para el usuario. En este documento, throughput de servicio significa finalizaciones por unidad de tiempo; goodput cuenta las que cumplen el resultado y plazo requeridos. Bajo contención severa, aumentar el tráfico puede incluso reducir ese goodput.

Feedback y Retry amplification

incoming work > service capacity
    -> queue grows
    -> latency grows
    -> timeouts
    -> retries
    -> additional load

timeout termina una espera local; no garantiza que el servidor haya detenido la ejecución. Si el cliente inicia retry mientras el intento anterior continúa, ambos pueden ocupar recursos. Si varias capas repiten, la amplificación se multiplica: tres capas con dos intentos cada una pueden producir hasta ocho llamadas finales por una intención original.

La repetición puede formar un feedback positivo: la lentitud provoca más intentos y esos intentos empeoran la lentitud. AWS analiza esta interacción entre overload, timeouts y retries en su explicación de load shedding. Using load shedding to avoid overload.

backoff reduce la frecuencia individual y jitter evita concentraciones sincronizadas, pero ninguno elimina una insuficiencia sostenida. Un presupuesto agregado de retries limita trabajo extra; sigue siendo necesario decidir qué trabajo nuevo aceptar y qué proteger.

Ejemplo transversal

Supongamos API Gateway → Order Service → Payment Service, con tráfico normal de 100 req/s y capacidad útil aproximada de 120 req/s para esa mezcla de operaciones. Un pico sostenido de 300 req/s ofrece un excedente inicial de 180 req/s. Si no hay rechazo ni otro control, el backlog aumenta aproximadamente en esa cantidad por segundo mientras la capacidad permanezca estable.

Tras diez segundos serían unos 1.800 pedidos adicionales esperando. Es una aproximación ilustrativa: no incorpora variabilidad, retries ni degradación por contención. Si Payment se vuelve lento, la capacidad puede caer y el cálculo deja de describir el sistema real.

Volver a 100 req/s tampoco vacía instantáneamente la cola. Con capacidad constante de 120, quedan apenas 20 req/s para drenarla; el backlog ilustrativo necesitaría unos 90 segundos. Trabajo vencido y repeticiones pendientes pueden prolongar la recuperación. retry-storms explica cuándo la repetición mantiene la carga; metastable-failures exige un efecto autosostenido tras retirar el trigger, no solo un backlog que tarda en drenarse. cascading-failures permite seguir cómo esta pérdida de capacidad alcanza otras dependencias.

Respuestas distintas a un problema común

Decisión	Relación con overload
admission-control	Decide si puede comprometerse capacidad ahora.
load-shedding	Sacrifica trabajo de forma deliberada para conservar salud.
backpressure	Comunica presión hacia quien produce trabajo.
flow-control	Acota lo que puede estar en tránsito entre participantes.
rate-limiting	Restringe operaciones conforme a una política temporal.
bulkhead	Conserva capacidad para grupos o dependencias protegidos.

Estas respuestas no son una pila obligatoria. Un límite de ingreso fijo puede quedar desactualizado; una partición protege otros flujos pero no vuelve sano a Payment. Agregar recursos ayuda solo si aumenta la capacidad del cuello de botella relevante.

Diagnóstico y recuperación

Observar llegadas originales y adicionales, edad de cola, espera, concurrencia, ocupación del recurso escaso, rechazos y finalizaciones útiles. Separar clases de trabajo y latencia de aceptados frente a rechazados evita que rechazos rápidos oculten una experiencia deteriorada.

Identificar overload es útil para dimensionar protección y probar recuperación bajo demanda excesiva o pérdida de capacidad. No usarlo como explicación universal de una latencia alta: errores deterministas, locks incorrectos o fallos de red requieren otro diagnóstico. La recuperación debe comprobar que el sistema vuelve a progresar sin liberar todo el backlog a la vez. load-and-flow-control organiza esas preguntas.