Cuando una aplicación depende de servicios internos o externos, la caída de uno de ellos no debería obligar automáticamente a detenerlo todo. Sin embargo, mantener todas las funciones como si nada ocurriera también puede provocar datos incoherentes, operaciones duplicadas o decisiones basadas en información desactualizada. Diseñar la degradación controlada consiste en decidir de antemano qué capacidades siguen disponibles, cuáles se limitan y cuáles deben bloquearse mientras una dependencia no responde.
La decisión debe proteger el proceso de negocio, no solo la disponibilidad técnica. Para cada función conviene considerar qué servicio necesita, qué ocurre si falta, cuánto tiempo puede tolerarse la interrupción y cómo se restablece la consistencia después. Así, el equipo puede ofrecer una alternativa útil sin ocultar el problema ni asumir riesgos innecesarios.
Qué significa degradar de forma controlada
Una aplicación está en degradación controlada cuando, ante un fallo o una respuesta insuficiente de una dependencia, conserva un conjunto deliberado de funciones con límites explícitos. No es una copia completa del servicio ni una promesa de que todo seguirá funcionando. Es una política de comportamiento para condiciones parciales de fallo.
Se diferencia de otros mecanismos relacionados:
- Modo sin conexión: permite usar ciertas funciones sin conectividad y, en algunos casos, sincronizar cambios más tarde. La degradación controlada también puede aplicarse cuando hay red, pero falla un servicio concreto.
- Reintentos: vuelven a intentar una solicitud fallida, normalmente con límites y pausas. No resuelven por sí solos qué debe ver o hacer la persona mientras la dependencia continúa indisponible.
- Degradación controlada: define la experiencia y las reglas de negocio durante el fallo, incluyendo qué operaciones se permiten, con qué datos y bajo qué restricciones.
Por ejemplo, si falla un servicio de recomendaciones, la aplicación puede mostrar una selección genérica y mantener la búsqueda. Si falla la validación necesaria para confirmar un pago, permitir el cobro de todos modos puede crear un riesgo mayor que interrumpir temporalmente esa acción.
Relaciona cada función con sus dependencias e impacto
Empieza por un mapa de capacidades del producto, no por un inventario aislado de servicios. Para cada función visible, registra qué dependencias necesita y qué resultado produce. Una ficha útil incluye la operación, el servicio requerido, los datos leídos o escritos, el efecto para el usuario y las consecuencias de un resultado incorrecto.
Después valora dos dimensiones: el impacto de no poder completar la función y el daño posible si se completa con información incompleta o incorrecta. No son equivalentes. Una demora para cargar contenido puede ser molesta, mientras que aceptar una transacción sin comprobar su estado puede generar pérdidas o problemas de conciliación.
Clasifica las funciones en tres grupos iniciales:
- Se pueden mantener: capacidades independientes de la dependencia caída, como consultar contenido que ya está disponible localmente.
- Se pueden limitar: acciones útiles si se acota su alcance, por ejemplo mostrar datos almacenados con su fecha de actualización o permitir guardar un borrador sin enviarlo.
- Se deben detener: operaciones cuya corrección depende de una comprobación que no puede realizarse, como confirmar una acción irreversible sin validar sus condiciones.
La clasificación debe contemplar alternativas y consecuencias para las áreas afectadas. Producto puede definir qué experiencia conserva valor; tecnología y operaciones deben confirmar qué fallos detectan y qué garantías ofrecen los sistemas. Revisad también las dependencias indirectas: una función puede parecer autónoma y, aun así, necesitar una validación posterior para completar el proceso.
Elige entre capacidad limitada, caché o alternativa manual
La opción adecuada depende de la antigüedad aceptable de los datos, de si la operación modifica el estado y de la posibilidad de reconciliar cambios después. No todas las cachés son seguras para cualquier uso: un dato útil para orientar una consulta puede ser inadecuado para autorizar una operación.
- Datos en caché: úsalos cuando la lectura siga siendo útil aunque no esté completamente actualizada. Indica su antigüedad y evita presentarlos como una confirmación vigente. Define cuándo dejan de ser aceptables; si no puedes establecer ese límite con criterio de negocio, no los uses para decisiones sensibles.
- Capacidad reducida: ofrece una parte de la función, como consultar información pero no modificarla, o preparar una solicitud sin enviarla. Explica qué paso queda pendiente y qué hará falta para completarlo.
- Alternativa manual: puede ser apropiada si hay un procedimiento claro, responsables asignados y un registro posterior. Sin esos controles, el trabajo manual puede crear duplicados y convertirse en una fuente paralela de datos.
- Bloqueo temporal: es preferible cuando la operación no puede ejecutarse con seguridad o verificarse después. Restringe la acción afectada, no necesariamente toda la aplicación.
Antes de permitir escrituras diferidas, concreta cómo se identifican, almacenan y reintentan las operaciones; qué respuesta recibe la persona; y cómo se resuelven conflictos. Si no hay una regla segura para estos casos, conservar la intención como borrador suele ser menos arriesgado que afirmar que la acción se completó.
Bloquea las operaciones que puedan dejar datos incoherentes
La pregunta clave es si el sistema puede distinguir entre una solicitud no recibida, una solicitud procesada cuya respuesta se perdió y una solicitud aún pendiente. Si no puede, repetir una operación sensible sin controles podría ejecutarla más de una vez. Los reintentos deben tener límites y adecuarse al tipo de solicitud; para acciones con efectos, hay que diseñar mecanismos que permitan reconocer duplicados y consultar el resultado antes de repetir.
Detén o limita una operación cuando:
- necesite una validación que está fuera de servicio y no exista una regla alternativa aprobada;
- pueda producir un efecto irreversible o difícil de compensar;
- no sea posible identificar si una solicitud anterior llegó a completarse;
- el dato almacenado haya superado el umbral de frescura aceptable para esa decisión.
Si existe una vía de compensación, documenta quién puede iniciarla y cómo se registra. No des por hecho que una acción compensatoria equivale a deshacer el efecto original: puede requerir intervención operativa, revisión o comunicación a la persona afectada. La política debe reflejar estas limitaciones.
Comunica el límite y recupera el servicio con control
El mensaje debe explicar qué función está limitada, qué puede hacer la persona ahora y si necesita repetir algún paso. Evita afirmaciones como “se ha completado” cuando solo se ha guardado una solicitud pendiente. Tampoco prometas un plazo de recuperación que el equipo no puede garantizar. Un estado claro reduce reintentos impulsivos y contactos evitables con soporte.
Al recuperarse la dependencia, no reactives ciegamente todo lo que quedó pendiente. Comprueba el estado real, procesa las operaciones según un orden definido, detecta duplicados y registra los resultados. Si existen conflictos entre cambios, aplica una regla acordada —por ejemplo, revisión antes de sobrescribir— y conserva trazabilidad suficiente para investigar discrepancias.
La recuperación debe tener condiciones observables. Comprueba que la dependencia responde de forma estable, que sus resultados son válidos y que la aplicación puede completar el flujo normal. Luego retira las restricciones de manera controlada. Si los síntomas vuelven, el sistema debe poder limitar de nuevo la función en lugar de oscilar entre disponible y fallida.
Prueba las decisiones y mide el resultado
Una política de degradación que solo existe en un documento no demuestra que la aplicación la aplique correctamente. Simula la caída, la latencia alta, los errores parciales y las respuestas tardías de cada dependencia importante. Comprueba tanto la pantalla como los registros, las operaciones pendientes y el comportamiento ante duplicados. Incluye pruebas de recuperación y de reconciliación, no solo de entrada en modo limitado.
Revisa señales técnicas y de negocio en conjunto. Entre las técnicas están los errores y tiempos de respuesta de la dependencia, el volumen de reintentos y la duración de la degradación. Entre las señales de negocio están las operaciones bloqueadas, las solicitudes pendientes, los conflictos encontrados y los casos que requieren intervención manual. Una mejora en disponibilidad no es suficiente si aumenta las transacciones incoherentes o la carga de soporte.
Como criterio práctico, para cada función responde y valida cuatro preguntas: qué se conserva, qué se limita, qué se bloquea y cómo se confirma la recuperación. Si el equipo no puede responderlas, aún no existe una estrategia completa. La degradación controlada convierte un fallo inevitable en una decisión explícita: mantener el valor que sigue siendo seguro y posponer lo que depende de una garantía que, temporalmente, ya no está disponible.