Degradación elegante: diseñar para que lo secundario falle sin tumbar lo esencial
Cuando un componente no crítico depende de un servicio externo, la pregunta de diseño más importante es qué pasa el día en que ese servicio no responde.
Todo sistema con suficiente tiempo en producción termina dependiendo de algún componente externo que, eventualmente, va a fallar: un motor de búsqueda especializado, un proveedor de geocodificación, un servicio de terceros que enriquece datos. La pregunta que separa un sistema resiliente de uno frágil no es si ese componente va a fallar, es qué le pasa al resto del sistema cuando lo hace.
El error más común: tratar todo como crítico
Es habitual que un fallo en un componente secundario, como un motor de búsqueda especializado que mejora la experiencia pero no es indispensable para el funcionamiento básico del producto, termine tumbando funcionalidad que no debería depender de él en absoluto. Esto ocurre porque el código no distingue entre "esto mejora la experiencia" y "esto es indispensable", y maneja ambos casos con el mismo nivel de rigidez: si el componente no responde, la funcionalidad completa se cae.
Diseñar la jerarquía de dependencias explícitamente
La alternativa no es evitar depender de servicios externos, eso es prácticamente imposible en cualquier sistema real. Es diseñar explícitamente qué pasa cuando cada dependencia falla, clasificando cada una según su criticidad real:
Dependencias con fallback funcional equivalente. Un motor de búsqueda especializado que ofrece mejor relevancia y velocidad puede tener, detrás, una consulta más simple contra la base de datos principal como respaldo. La experiencia se degrada (resultados menos refinados, quizás más lentos) pero la funcionalidad no desaparece.
Dependencias con fallback parcial. Un servicio de enriquecimiento de datos que no responde puede simplemente omitirse, mostrando la información base sin el enriquecimiento, en lugar de bloquear toda la operación.
Dependencias genuinamente críticas. Para estas, no existe fallback razonable, y la pregunta de diseño correcta no es cómo degradar, sino cómo maximizar la disponibilidad de esa dependencia específica (redundancia, réplicas, monitoreo agresivo), porque su fallo sí debe considerarse un incidente de todo el sistema.
Por qué esto no es solo "buenas prácticas" abstractas
Clasificar dependencias de esta forma cambia decisiones concretas de arquitectura. Determina si una llamada a un servicio externo debe ser bloqueante o puede ejecutarse con un timeout corto y un resultado por defecto. Determina si un fallo se registra como una alerta silenciosa (algo se degradó, pero el usuario no lo notó) o como un incidente que despierta a alguien a las 3 de la mañana. Sin esa clasificación explícita, todas las dependencias terminan tratadas, por defecto, como si fueran igual de críticas, que casi nunca es cierto y casi siempre es más caro de lo necesario.
La lección
La resiliencia no viene de eliminar dependencias externas, viene de decidir con claridad qué pasa cuando cada una falla, antes de que falle en producción. Un sistema que se degrada con gracia no es uno que nunca tiene problemas. Es uno donde el problema de un componente secundario se queda contenido en ese componente, en lugar de propagarse a funcionalidad que nunca debió depender de él para empezar.