Graceful degradation to świadome ograniczenie funkcji podczas awarii tak, aby zachować bezpieczną i użyteczną część usługi. Zaczyna się od rozróżnienia funkcji podstawowej i dodatków, nie od ignorowania błędów.

Przykład

Scenariusz edukacyjny inspirowany praktyką: dokument został wygenerowany, ale opcjonalne zapisanie kopii nie powiodło się. Użytkownik nadal może przeczytać i pobrać dokument. Komunikat powinien rozdzielać dwa wyniki: „Dokument jest gotowy. Kopii nie zapisano”.

Jak zaprojektować granicę?

  1. Ustal, co oznacza sukces głównej operacji i które funkcje można ograniczyć.
  2. Ogranicz czas oczekiwania na zależność, aby dodatek nie blokował całej odpowiedzi.
  3. Zachowaj dostępny wynik i pokaż uczciwy komunikat o ograniczeniu.
  4. Monitoruj awarię i powrót zależności bez rejestrowania poufnej treści.

Czego ten wzorzec nie załatwia?

Nie gwarantuje późniejszego zapisania kopii. Taką gwarancję wymagałby osobny, trwały mechanizm i obsługa błędów. Nie zastępuje też izolacji zasobów: jeśli dodatek wyczerpie wspólną pulę połączeń, sama obsługa wyjątku może nie ochronić usługi.

Funkcja obowiązkowa to inna sytuacja

Przyjęcie zamówienia wymagające trwałego zapisu nie kończy się sukcesem tylko dlatego, że ekran pokazał potwierdzenie. Podobnie kontroli uprawnień nie można pominąć przy awarii. Wymagania określają, co można ograniczyć, a co musi zakończyć się potwierdzonym sukcesem albo jawnym niepowodzeniem.

Przećwicz błąd zapisu → · Źródło: Azure — self-preservation i graceful degradation