Qué es la degradación gradual en sistemas y cómo diseñarla

Un servicio no siempre puede entregar todas sus funciones con la misma capacidad. Si una dependencia está lenta o llega una ráfaga de tráfico, la degradación gradual conserva la operación principal y retira, limita o posterga partes menos importantes. El usuario recibe una respuesta útil en lugar de una caída completa.

También puede servirte: Observabilidad: qué es y cómo usar logs, métricas y trazas

AWS recomienda diseñar qué funciones pueden reducirse cuando faltan recursos y aislar los fallos para que no derriben todo el servicio. No se trata de ocultar un incidente: la respuesta debe informar sus límites y registrar qué componente fue desactivado o reemplazado.

La prioridad depende del producto. En una tienda, confirmar un pedido puede ser más importante que recomendar productos; en una aplicación de mapas, mostrar una ruta puede ser más importante que cargar reseñas. La decisión debe estar escrita antes del incidente, porque durante una sobrecarga no hay tiempo para discutir cada detalle.

La primera decisión es ordenar el trabajo por valor y costo. Peticiones críticas pueden tener una cola o un cupo reservado, mientras que tareas pesadas y diferibles se procesan más tarde. Una cola de prioridad permite elegir qué elemento sale primero, pero no elimina la necesidad de fijar un máximo para el tiempo de espera.

Google SRE describe la sobrecarga como una situación en la que una parte del sistema no puede atender todo lo que recibe. Rechazar temprano o reducir el trabajo puede ser más seguro que aceptar cada solicitud y agotar memoria, conexiones y procesos hasta que todas fallen.

El límite debe aplicarse cerca del recurso que se protege. Una pantalla que oculta botones no evita que el backend siga llamando a una dependencia cara. La API, el worker y la cola deben compartir la política de prioridad, de modo que una función desactivada no continúe consumiendo capacidad por detrás.

Una caché puede responder con el último dato válido cuando una fuente externa está lenta, siempre que se indique su fecha y su alcance. Para una cotización o un inventario, el producto debe decidir si un dato antiguo sirve para leer o si sólo puede mostrar un mensaje de espera. Presentar un valor vencido como actual puede causar más daño que un error visible.

Las respuestas parciales reducen trabajo cuando una pantalla reúne varios módulos. El servicio puede entregar el contenido central y marcar qué bloque no pudo cargar. Esa separación evita que una recomendación, un gráfico o una imagen adicional bloquee una acción esencial.

También se puede bajar la calidad de forma controlada: menos campos, menor frecuencia de actualización o un modelo más pequeño para tareas secundarias. La elección debe tener un criterio de salida y una señal para volver al modo completo. Si el modo reducido queda activo sin límite, se convierte en una degradación permanente.

NGINX recomienda controlar las colas y limitar el trabajo pendiente cuando un servidor se acerca a su capacidad. El objetivo es mantener respuestas previsibles, no acumular solicitudes hasta que el tiempo de espera las vuelva inútiles. Un timeout y un límite de cola deben trabajar juntos para liberar recursos.

La recuperación debe ser progresiva. Cuando la dependencia vuelve, probá una pequeña proporción de tráfico y observá errores, latencia y consumo antes de reactivar todo. Un circuito abierto o un limitador puede permanecer en modo protegido mientras se verifica que la mejora sea estable.

Las métricas deben separar tráfico aceptado, rechazado y degradado. Medí qué función se retiró, cuánto tiempo duró, cuántos usuarios recibieron una alternativa y si aumentaron los reintentos. Sin ese contexto, el promedio de latencia puede parecer normal aunque el producto haya escondido una parte esencial.

Listá las funciones del producto y ordenalas por impacto para el usuario. Para cada una, definí si puede usar caché, datos parciales, una cola, un resultado reducido o un rechazo rápido. Especificá qué mensaje recibe la persona y qué dato se registra cuando se activa el modo protegido.

Probá la dependencia lenta, la falta de memoria, el aumento de conexiones y la recuperación intermitente. Verificá que el sistema reduzca trabajo antes de quedar sin recursos y que las rutas críticas mantengan su cupo. Probá también que una función secundaria no pueda reactivar la carga completa por accidente.

Por último, elegí las señales para salir de la degradación y quién puede cambiar la política. Una alerta debe mostrar el motivo, la duración y el porcentaje de tráfico afectado. La degradación gradual es una decisión de producto y arquitectura: conserva el servicio que importa, hace explícito el costo y permite recuperar sin una caída brusca.