Che cosa è il graceful degradation quando una dipendenza fallisce?

Question

Accepted Answer

**Graceful degradation** significa che quando una dipendenza fallisce, il sistema **mantiene il flusso principale in esecuzione** fornendo un'esperienza ridotta o parziale invece di restituire un errore. L'obiettivo è **fallire soft**, non fallire hard: una pagina degradata è meglio di un 500.

## Tecniche

- **Fail soft** — quando una dipendenza è giù, servi **dati in cache, parziali o di default** anziché lanciare un errore. Un risultato stale ma presente è solitamente meglio di nulla.
- **Feature-flag dei percorsi non critici** — spegni raccomandazioni, analytics o widget elaborati, così un fallimento lì non può rompere la pagina principale.
- **Timeouts + fallbacks** — non aspettare mai per sempre una dipendenza lenta; vai in timeout e passa a un valore o percorso di fallback.
- **Isolate failures (bulkheads)** — partiziona le risorse (thread pool, connection pool) per dipendenza, così un servizio che fallisce non può esaurire tutto e trascinare il resto.
- **Proteggi il flusso principale** — identifica il percorso che deve funzionare (browse, checkout) e assicurati che le funzionalità non essenziali non possano mai abbatterlo.

## Esempio: il backend di ricerca è giù

```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
```

Invece di una pagina morta, l'utente riceve risultati in cache e un piccolo avviso, mentre la navigazione e il checkout continuano a funzionare. Il fallimento è contenuto in una sola funzionalità.

## Perché è importante

Le dipendenze *falliranno* — API di terze parti, cluster di ricerca, servizi di raccomandazione. Senza graceful degradation, un qualsiasi fallimento a cascata diventa un'interruzione totale. Progettare per fallire soft (dati in cache/parziali/default), flagging dei percorsi non critici, timeout con fallback, e isolamento dei fallimenti con bulkhead mantiene il prodotto utilizzabile durante fallimenti parziali — che è la differenza tra un piccolo problema e un incidente importante.