Wzorzec Saga i operacje kompensacyjne w automatyzacji

Wzorzec Saga porządkuje proces, który przechodzi przez kilka niezależnych usług, a każda z nich zapisuje własny stan. Zamiast jednej wspólnej transakcji baza danych, CRM, płatność i automatyzacja wykonują lokalne kroki. Jeśli wszystkie się powiodą, sprawa kończy się sukcesem. Jeśli późniejszy krok zawiedzie, system nie może zwykle nacisnąć jednego „cofnij”. Uruchamia więc z góry zaprojektowane operacje kompensacyjne dla kroków już wykonanych. AWS opisuje Sagę jako wzorzec zarządzania błędami i spójnością w rozproszonych aplikacjach.

To ma praktyczny sens także poza mikroserwisami. Załóżmy, że ekspert sprzedaje dostęp do warsztatu. Workflow zapisuje zakup w systemie płatności, tworzy kontakt w CRM, nadaje dostęp do materiałów i wysyła potwierdzenie. Gdy nadanie dostępu zawiedzie, płatność mogła już przejść, a kontakt zostać utworzony. Saga wymusza odpowiedź na niewygodne pytanie przed uruchomieniem automatu: co dokładnie dzieje się wtedy z każdym wcześniejszym krokiem? Możliwa kompensacja to oznaczenie zamówienia do obsługi, odebranie błędnie nadanego dostępu lub zwrot po potwierdzeniu przez człowieka. Nie każda sytuacja powinna kończyć się automatycznym zwrotem.

Operacja kompensacyjna nie musi przywracać systemu do identycznego stanu sprzed procesu. To ważne ograniczenie. Jeśli automatyzacja wysłała wiadomość, nie da się jej „odwysłać”. Jeśli wystawiono fakturę albo zapisano dane w zewnętrznej usłudze, odwrócenie może wymagać osobnej reguły biznesowej, a czasem ręcznej interwencji. Microsoft wskazuje, że kompensacja jest specyficzna dla aplikacji i powinna uwzględniać równoległe zmiany, zamiast bezmyślnie nadpisywać poprzedni stan. Dlatego w systemie AI lepiej odwracać dostęp, status lub rezerwację niż próbować ukryć skutki komunikacji wysłanej do klienta.

Saga różni się od retry, timeoutu i kolejki błędów. Retry powtarza pojedyncze przejściowo nieudane wywołanie. Timeout określa, kiedy przestać czekać. Kolejka błędów odkłada sprawę, której nie udało się przetworzyć. Saga opisuje całą sprawę i zależności między jej krokami, także to, co zrobić po częściowym sukcesie. W praktyce te mechanizmy współpracują: najpierw ograniczasz czas i bezpiecznie ponawiasz krok, potem uruchamiasz kompensację lub przekazujesz sprawę do kolejki błędów. Bez tego rozróżnienia automatyzacja często wykonuje ten sam krok drugi raz albo porzuca klienta między płatnością a dostępem.

Najprostszą formą jest orkiestracja: jeden workflow zna kolejność, zapisuje identyfikator sprawy i po każdym kroku wie, czy przejść dalej, wykonać kompensację czy poprosić człowieka o decyzję. Druga forma to choreografia, gdzie usługi reagują na zdarzenia po sobie. Dla solopreneurki centralny workflow jest zwykle czytelniejszy, bo można w jednym miejscu zobaczyć stan zamówienia i reguły błędów. AWS podkreśla, że orkiestrator zwiększa złożoność, a przy wielu uczestnikach potrzebne są logi i śledzenie. Nie buduj choreografii tylko dlatego, że brzmi „bardziej technicznie”.

Każdy krok oraz jego kompensacja powinny być idempotentne, czyli bezpieczne przy ponownym wykonaniu. Awaria może nastąpić po zapisaniu wyniku, ale przed odpowiedzią do workflowu. Wtedy ponowienie nie może drugi raz dodać osoby do płatnego programu ani zwrócić pieniędzy dwa razy. Zapisuj identyfikator sprawy, identyfikator zewnętrznego obiektu, aktualny stan i wynik każdej próby. Microsoft zaleca zapisywanie postępu, aby dało się wznowić również samą kompensację, która także może zawieść. Sam komunikat „błąd webhooka” nie jest wystarczającym stanem procesu.

Nie używaj Sagi do każdej automatyzacji. Jeśli dwa zapisy dzieją się w jednej bazie danych i mogą być objęte zwykłą transakcją, to prostsze rozwiązanie jest lepsze. Jeśli krok jest nieodwracalny lub wymaga osądu, na przykład publikacja posta, zmiana ceny albo decyzja prawna, przewidź stan oczekujący na zatwierdzenie zamiast fikcyjnej kompensacji. Wzorzec zwiększa koszt utrzymania, opóźnienie i liczbę scenariuszy testowych. Jego wartość pojawia się wtedy, gdy częściowy sukces ma realny koszt dla klienta albo marki.

Zacznij od jednego krytycznego przepływu, na przykład zakup, zapis na konsultację lub przyjęcie leada. Rozpisz kolejno: wejście, właściciela kroku, dane potrzebne do jego odwrócenia, retry, limit czasu, kompensację i warunek przekazania sprawy człowiekowi. Przetestuj awarię po każdym kroku oraz ponowne uruchomienie tego samego identyfikatora sprawy. Dopiero gdy potrafisz odpowiedzieć, co zobaczy klient i co zostanie w CRM po każdym z tych testów, workflow jest gotowy do produkcji. Powiąż ten wzorzec z idempotencją, kolejką błędów i webhookami, aby cały proces, a nie tylko jego szczęśliwa ścieżka, był kontrolowany.