Compensarea saga are nevoie de propriul plan de recuperare

Un flux de lucru poate eșua după ce alt sistem a acceptat deja operația cerută. Raportarea unei erori nu retrage acea acțiune externă. O saga are, așadar, nevoie de un al doilea proiect: ce face compensarea, cum poate eșua și cine rezolvă incertitudinea rămasă. Alegerea unui motor pentru fluxuri de lucru nu stabilește aceste decizii de afaceri.

În articolul din 25 iunie 2026 despre rollback pentru saga, Cloudflare plasează compensarea lângă pasul inițial și execută funcțiile eligibile în ordinea inversă a începerii pașilor. Sunt reguli utile de execuție. Ele nu pot stabili că o acțiune externă are o operație inversă cu sens pentru afacere. Această distincție trebuie să intre în cerințe înainte de implementare.

Revenirea presupune o nouă acțiune

Compensarea modifică din nou situația. Nu poate face ca acțiunea inițială să nu fi avut loc. Când cerințele numesc o operație reversibilă, precizați ce rezultat trebuie restabilit și ce consecințe rămân acceptabile. Restabilirea unui echilibru comercial poate lăsa în urmă istoricul ambelor acțiuni, un interval între ele și muncă pentru cineva din afara fluxului.

Limita importantă este cine controlează datele. Într-o singură bază de date controlată de aplicație, o tranzacție locală poate păstra atomicitatea unui grup de modificări. Între servicii care confirmă independent operațiile, coordonatorul nu poate face să dispară acele confirmări. Tutorialul Google din 4 februarie 2022 despre saga explică, drept context, asocierea tranzacțiilor locale cu operații de compensare. Precede cu ani anunțul Cloudflare; nu reprezintă o altă lansare din iunie.

Folosiți distincția pentru a verifica alegerea arhitecturii. Dacă presupusa tranzacție distribuită atinge doar o bază de date proprie, o tranzacție locală este, de regulă, punctul de plecare mai simplu. O saga introduce stări intermediare și obligații de recuperare. Complexitatea ar trebui justificată de o separare reală între sisteme, nu de preferința pentru un tipar la modă.

Ordinea nu stabilește corectitudinea operațiilor

Funcțiile de compensare definite la nivelul pasului țin acțiunea inițială și recuperarea suficient de aproape pentru a fi analizate împreună. Cloudflare descrie ordinea inversă a începerii, nu a încheierii pașilor. Distincția contează când pașii se suprapun. Momentul încheierii nu descrie fidel felul în care au fost inițiate operațiile.

O regulă de ordine spune totuși doar ce funcție rulează prima. Nu dovedește că o operație comercială poate urma în siguranță după alta. Notați separat dependențele dintre compensări. Dacă ordinea aleasă nu le poate respecta, schimbați proiectarea fluxului sau politica de recuperare. Nu presupuneți implicit că inversarea unei liste reconstruiește situația inițială a afacerii.

Din același motiv, compensarea diferă de salvarea stării intermediare a unei sarcini. Coordonatorul poate reține corect fiecare valoare salvată, în timp ce alt serviciu a acceptat o acțiune al cărei rezultat nu a mai ajuns la el. Îmbunătățirea serializării nu poate reconcilia singură această diferență. Recuperarea trebuie să țină cont de starea serviciului extern și de sensul cererii inițiale.

Lipsa rezultatului este o stare reală

Cloudflare include explicit situația în care un pas eșuat a înregistrat compensarea, dar nu a salvat rezultatul. Funcția sa trebuie să accepte output === undefined. Un pas care nu a returnat un rezultat poate să fi interacționat deja cu un sistem extern. Dacă lipsa rezultatului devine dovada că nu s-a întâmplat nimic, tocmai cazul incert rămâne netratat.

Pentru fiecare acțiune externă, definiți cum deosebiți finalizarea confirmată, nefinalizarea confirmată și rezultatul necunoscut. Ultima categorie are nevoie de un identificator disponibil chiar dacă valoarea returnată lipsește. Stabiliți ce dovezi poate furniza sistemul extern și ce face aplicația cât timp ele nu sunt disponibile. Presupunerea unui rezultat și repetarea acțiunii inițiale pot produce un nou efect.

Idempotența este necesară și pentru acțiunea de compensare. Pentru a fi idempotentă, compensarea repetată trebuie să conducă la ajustarea intenționată, nu să o multiplice fără limită. Politica de idempotență a operației inițiale nu acoperă automat o altă cerere, făcută în sens invers. Analizați separat identificatorul, domeniul și durata de păstrare pentru fiecare operație.

Recuperarea trebuie să reziste eșecului compensării

Utilitatea recuperării automate depinde de regulile ei de oprire. Decideți ce erori justifică o nouă încercare și când intervine o persoană. Un refuz comercial definitiv și o eroare temporară de transport nu ar trebui tratate prin aceeași buclă de reîncercare. Așteptarea nu poate crea o permisiune comercială pe care operația de compensare nu o are.

Persoana responsabilă are nevoie de context pentru a interveni: intenția inițială, rezultatul extern cunoscut, încercările de compensare și incertitudinea rămasă. Păstrați eșecul inițial separat de progresul recuperării. Altfel, operatorul poate vedea că recuperarea a eșuat fără să poată afla ce încerca aplicația să remedieze.

Definiți reușita atât comercial, cât și tehnic. Încheierea cu succes a unei funcții oferă informații utile despre acea funcție. Întrebarea mai largă este dacă ajustarea necesară a fost confirmată, dacă operațiile dependente pot continua și dacă mai există obligații restante. Un flux marcat ca eșuat poate necesita în continuare atenție, după oprirea tuturor reîncercărilor automate.

Alegeți o separare pe care o puteți gestiona

Cel mai puternic argument pentru saga este practic: sistemele independente confirmă deja separat operațiile, iar recuperarea explicită poate fi mai clară decât tratarea erorilor în locuri disparate. Argumentul convinge când afacerea acceptă inconsistența temporară și are o politică de compensare aplicabilă. Devine mai slab când promisiunea cerută este finalizarea indivizibilă a unor acțiuni care nu pot fi compensate.

Înainte de alegerea motorului, analizați pe hârtie un eșec al acțiunii inițiale și unul al compensării. Numiți dovezile necesare reluării, persoana care poate interveni și condiția închiderii cazului. În dezvoltarea software la comandă, aceste decizii intră în cerințele agreate. Rezultatul util este un plan pe care afacerea îl poate aplica atunci când recuperarea automată își atinge limita.