Fiecare echipă care livrează un sistem agentic ajunge eventual la aceeași întrebare, de obicei pe la luna trei: „ne trebuie Temporal / Inngest / Restate, sau putem doar să adăugăm retries?"
Răspunsul e aproape întotdeauna „ai nevoie de orchestrator durabil, dar dintr-un motiv care nu e «retries»."
Ce rezolvă efectiv retries
Retries sunt instrumentul potrivit când un eșec tranzitoriu e observat de același proces care a făcut apelul. Sughiț de rețea, răspuns de rate-limit, un downstream instabil — apelantul are rezultatul eșuat în mână, știe ce încerca să facă și poate pur și simplu să încerce din nou.
Pentru asta îți trebuie: o politică de retry cu exponential backoff, un cap de încercări maxime și idempotență pe receiver. Asta e o librărie, nu un sistem. p-retry, tenacity, tokio-retry — alege una și mergi mai departe.
Ce rezolvă efectiv execuția durabilă
Execuția durabilă e instrumentul potrivit când procesul în sine poate muri între pași. Crash, deploy, k8s care evictează pod-ul, un apel LLM de 30 de minute care depășește request timeout-ul — întrebarea nu e „putem încerca din nou" ci „unde eram când s-au stins luminile și cum reluăm fără să refacem părțile care deja au reușit?"
E o problemă fundamental diferită. Are nevoie de:
- Stare persistentă a pașilor — un log al pașilor finalizați, cu rezultatele lor.
- Istoric reluabil — când procesul reia, parcurge log-ul, sare peste pașii finalizați și continuă de la primul nefinalizat.
- Granițe deterministe între pași — cod structurat astfel încât orchestratorul să identifice pașii fără ambiguitate la replay.
Poți să scrii asta de la zero. Lumea o face. Sunt șase luni de debugging la race conditions până realizezi că ai construit o versiune mai proastă de Temporal.
Decizia propriu-zisă
Dacă sistemul tău agentic are:
- Tool calls care iau mai mult de câteva secunde individual,
- Workflow-uri cu mai mult de ~3 pași secvențiali,
- Un handoff sau human-in-the-loop undeva pe la mijloc,
- SLA-uri care nu pot tolera o repornire de deploy care cauzează un eșec vizibil utilizatorului,
…ai nevoie de un orchestrator durabil. Nu „poate ai vrea unul pentru nice-to-have." Ai nevoie de unul, iar adăugarea lui ulterioară va fi mult mai scumpă decât să începi cu el.
Dacă sistemul tău e scurt, sincron și stateless (un prompt, un răspuns, gata în 5 secunde), retries sunt în regulă. Nu over-engineer.
Ce livrăm
În practică, default-ul nostru e Temporal sau Restate (în funcție de stack-ul de limbaj), cu cod de workflow structurat astfel încât fiecare apel LLM, invocare de tool și aprobare să fie un pas separat. Costul e ceva curbă de învățare și un runtime de operat. Beneficiul e că „ce se întâmplă când procesul crapă în mijlocul workflow-ului" încetează să fie o întrebare la care trebuie să răspundem pentru fiecare feature nou — orchestratorul răspunde o singură dată.
Retries rezolvă „acest apel a eșuat." Execuția durabilă rezolvă „acest workflow trebuie să supraviețuiască eșecurilor lucrului care îl rulează." Nu sunt alternative — majoritatea sistemelor de producție au nevoie de ambele și pe al doilea îl subestimează lumea.