¿Qué es la degradación elegante cuando falla una dependencia?

Question

Accepted Answer

**Graceful degradation** significa que cuando una dependencia falla, el sistema **mantiene el flujo principal funcionando** al servir una experiencia reducida o parcial en lugar de devolver un error. El objetivo es **fallar suavemente**, no fallar bruscamente: una página degradada es mejor que un 500.

## Técnicas

- **Fallar suavemente** — cuando una dependencia está caída, sirve datos **cacheados, parciales o por defecto** en lugar de un error. Un resultado antiguo pero presente suele ser mejor que nada.
- **Feature-flag de rutas no críticas** — desactiva recomendaciones, análisis o widgets elegantes para que un fallo ahí no pueda romper la página principal.
- **Timeouts + fallbacks** — nunca esperes para siempre una dependencia lenta; agota el timeout y cambia a un valor o ruta de fallback.
- **Aisla fallos (bulkheads)** — particiona recursos (thread pools, connection pools) por dependencia para que un servicio que falla no pueda agotar todo y arrastrar el resto.
- **Protege el flujo principal** — identifica la ruta que debe funcionar (navegar, checkout) y asegúrate de que las características no esenciales nunca puedan tirarla.

## Ejemplo: el backend de búsqueda está caído

```text
BAD  (fail hard):
  search() → backend timeout → throw → user sees HTTP 500 (whole page dead)

GOOD (fail soft):
  result = search()
         catch timeout → return cached_results OR empty + notice
  page renders:
    [ "Showing recent results — live search is temporarily unavailable." ]
    + cached listings, working nav, working checkout
  → user keeps browsing; core flow intact
```

En lugar de una página muerta, el usuario obtiene resultados cacheados y un pequeño aviso, mientras que la navegación y el checkout siguen funcionando. El fallo está contenido en una sola característica.

## Por qué es importante

Las dependencias *fallarán* — API de terceros, clusters de búsqueda, servicios de recomendación. Sin degradación elegante, cualquier fallo se propaga en una interrupción completa. Diseñar para fallar suavemente (datos cacheados/parciales/por defecto), desactivar rutas no críticas, timeouts con fallbacks e aislar fallos con bulkheads mantiene el producto usable durante fallos parciales — que es la diferencia entre un pequeño problema y un incidente mayor.