Wyłącznik awaryjny w automatyzacji (circuit breaker)

Circuit breaker, czyli wyłącznik awaryjny, jest wzorcem odporności dla połączeń z API i usługami zewnętrznymi. Jeżeli dany endpoint wielokrotnie zawodzi, mechanizm na pewien czas blokuje kolejne wywołania. Proces nie czeka wtedy na następny timeout i nie dokłada ruchu do usługi, która najpewniej nadal nie działa. To odpowiednik bezpiecznika elektrycznego: odcina obwód przy anomalii, zamiast pozwalać problemowi rozlać się na resztę systemu.

Klasyczny circuit breaker ma trzy stany. W stanie zamkniętym przepuszcza wywołania i liczy niepowodzenia. Po przekroczeniu ustalonego progu przechodzi do stanu otwartego, w którym odrzuca kolejne żądania od razu, bez kontaktu z usługą. Po czasie chłodzenia wchodzi w stan półotwarty: przepuszcza pojedyncze lub nieliczne próby kontrolne. Sukces zamyka obwód, a kolejna porażka otwiera go ponownie. Microsoft opisuje ten stan jako ochronę usługi, która dopiero odzyskuje sprawność.

To ma praktyczne znaczenie także poza dużą architekturą. Soloprzedsiębiorca może mieć workflow: formularz kontaktowy, wzbogacenie leada przez model AI, zapis w CRM i wysyłka potwierdzenia. Jeśli API modelu zacznie zwracać timeouty, bezpiecznik może chwilowo pominąć enrichment, zapisać lead w CRM i oznaczyć zadanie do późniejszego uzupełnienia. Zamiast całkowicie zatrzymać pozyskiwanie kontaktów albo generować dziesiątki kosztownych prób, system działa w ograniczonym, uczciwym trybie.

Circuit breaker nie zastępuje retry. Ponawianie z wykładniczym opóźnieniem ma sens przy błędzie krótkotrwałym, na przykład odpowiedzi 429 lub pojedynczym zerwaniu sieci. Wyłącznik reaguje, gdy błędy się powtarzają i istnieje ryzyko dłuższej awarii. Dobra kolejność jest prosta: ograniczona liczba bezpiecznych prób z rosnącym opóźnieniem, a po ich wyczerpaniu otwarcie obwodu dla danego dostawcy. Każdy retry musi uszanować otwarty obwód i nie obchodzić tej ochrony.

Próg nie może być zgadywaniem. Ustal go na podstawie rzeczywistego procesu: jak często wywołujesz usługę, który błąd uznajesz za przejściowy i czy istnieje bezpieczny fallback. Na przykład trzy timeouty w ciągu dwóch minut mogą otwierać obwód na pięć minut, a później pozwolić na jedną próbę kontrolną. Osobno traktuj błędy danych i autoryzacji. Nie otwieraj obwodu dla 400 po źle zbudowanym payloadzie, bo to błąd do naprawy, a nie sygnał o niedostępności dostawcy.

Widoczność jest częścią wzorca. Loguj przejścia między stanami, powód otwarcia, liczbę odrzuconych zadań i działanie fallbacku. Właściciel systemu powinien wiedzieć, że automatyzacja celowo ominęła zewnętrzny krok, a nie myśleć, że lead zniknął. AWS zaleca obserwowalność otwartego obwodu, a Google wskazuje circuit breaker jako ochronę przed awariami kaskadowymi także w obciążeniach AI i ML. W praktyce alert po otwarciu obwodu jest bardziej użyteczny niż setki identycznych alertów o timeoutach.

Największe ograniczenie: wyłącznik nie naprawia usługi ani złego projektu integracji. Może błędnie odciąć sprawny endpoint, jeśli próg jest zbyt agresywny, albo nie ochronić procesu, gdy próg jest za wysoki. Nie stosuj go do każdego pojedynczego kroku tylko dlatego, że brzmi technicznie. Użyj go tam, gdzie powtarzające się błędy zewnętrznej zależności mogą blokować ważny workflow, generować koszty albo psuć doświadczenie klienta. Zawsze zaprojektuj komunikat, kolejkę do odrobienia pracy albo świadomie ograniczoną funkcję zastępczą.