Co to jest degradacja elegancka, gdy zależność się nie powiedzie?

Question

Accepted Answer

**Degradacja elegancka** oznacza, że gdy zależność ulegnie awarii, system **utrzymuje przepływ główny w stanie działającym** poprzez serwowanie zmniejszonego lub częściowego doświadczenia zamiast zwracania błędu. Celem jest **miękkie niepowodzenie**, a nie twarde: zdegradowana strona jest lepsza niż 500.

## Techniki

- **Miękkie niepowodzenie** — gdy zależność jest niedostępna, serwuj **dane z cache, częściowe lub domyślne** zamiast błędu. Przestarzały, ale obecny wynik jest zwykle lepszy niż nic.
- **Flagi funkcji wyłączające ścieżki niekrytyczne** — wyłącz rekomendacje, analitykę lub zaawansowane widżety, aby awaria tam nie mogła zniszczyć głównej strony.
- **Limity czasu + fallbacki** — nigdy nie czekaj w nieskończoność na wolną zależność; przekrocz limit czasu i przełącz się na wartość fallbacku lub alternatywną ścieżkę.
- **Izolacja awarii (bulkheads)** — podziel zasoby (thread poole, connection poole) na zależność, aby jedna niedziałająca usługa nie mogła wyczerpać wszystkiego i nie wlokła reszty w dół.
- **Ochrona głównego przepływu** — zidentyfikuj ścieżkę krytyczną (przeglądanie, checkout) i upewnij się, że nieistotne funkcje nigdy nie mogą jej zniszczyć.

## Przykład: backend wyszukiwania jest niedostępny

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

Zamiast martwej strony, użytkownik otrzymuje wyniki z cache i małą notatkę, podczas gdy nawigacja i checkout dalej działają. Awaria jest ograniczona do jednej funkcji.

## Dlaczego to ważne

Zależności *będą* się nie powiodły — zewnętrzne API, klastry wyszukiwarek, usługi rekomendacji. Bez degradacji eleganckiej każda pojedyncza awaria kaskadowo prowadzi do całkowitej awarii. Projektowanie do miękkiego niepowodzenia (dane z cache/częściowe/domyślne), wyłączanie ścieżek niekrytycznych, limitowanie czasu z fallbackami i izolacja awarii za pomocą bulkheads utrzymuje produkt w użytkowania podczas częściowych awarii — co jest różnicą między drobnym problemem a poważnym incydentem.