Ogni team che rilascia un sistema con agenti IA prima o poi pone la stessa domanda, di solito intorno al terzo mese: "ci serve Temporal / Inngest / Restate, o bastano i retries?"
La risposta è quasi sempre "le serve l'orchestratore durable, ma per una ragione che non è 'retries.'"
Cosa risolvono davvero i retries
I retries sono lo strumento giusto quando un guasto transitorio viene osservato dallo stesso processo che ha emesso la chiamata. Un calo di rete, una risposta di rate-limit, un servizio downstream instabile — il chiamante ha in mano il risultato fallito, sa cosa stava cercando di fare, e può semplicemente riprovare.
Per questo serve: una policy di retry con backoff esponenziale, un tetto al numero di tentativi, e idempotenza sul ricevitore. È una libreria, non un sistema. p-retry, tenacity, tokio-retry — ne scelga una e vada avanti.
Cosa risolve davvero la durable execution
La durable execution è lo strumento giusto quando il processo stesso può morire tra uno step e l'altro. Crash, deploy, k8s che fa evict del pod, una chiamata LLM da 30 minuti che supera il timeout della richiesta — la domanda non è "possiamo riprovare" ma "dov'eravamo quando si sono spente le luci, e come riprendiamo senza rifare le parti già riuscite?"
Questo è un problema fondamentalmente diverso. Richiede:
- Stato degli step persistente — un log degli step completati, con i loro risultati.
- Storia rieseguibile — quando il processo riparte, percorre il log, salta gli step finiti e prosegue dal primo non finito.
- Confini di step deterministici — codice strutturato in modo che l'orchestratore possa identificare gli step in modo non ambiguo attraverso le rieseguzioni.
Si può scrivere da zero. Lo fanno in molti. Sono sei mesi di debug di race condition prima di rendersi conto di aver costruito una versione peggiore di Temporal.
La decisione vera
Se il suo sistema con agenti IA ha:
- Tool call che individualmente impiegano più di pochi secondi,
- Workflow con più di ~3 step sequenziali,
- Un passaggio di consegne o un human-in-the-loop a metà strada,
- SLA che non tollerano che un restart da deploy causi un fallimento visibile all'utente,
…le serve un orchestratore durable. Non "magari le farebbe comodo per avere qualcosina in più." Le serve, e aggiungerlo dopo sarà molto più costoso che partire con lui.
Se il suo sistema è breve, sincrono e stateless (un prompt, una risposta, finito in 5 secondi), i retries vanno bene. Non esageri con l'ingegnerizzazione.
Cosa rilasciamo
In pratica, il nostro default è Temporal o Restate (a seconda dello stack di linguaggio), con il codice del workflow strutturato in modo che ogni chiamata LLM, ogni invocazione di tool, e ogni approvazione sia uno step separato. Il costo è una curva di apprendimento e un runtime da gestire. Il beneficio è che "cosa succede quando questo processo crasha a metà workflow" smette di essere una domanda a cui rispondere per ogni nuova funzionalità — l'orchestratore risponde una volta per tutte.
I retries risolvono "questa chiamata è fallita." La durable execution risolve "questo workflow deve sopravvivere ai guasti della cosa che lo esegue." Non sono alternative — la maggior parte dei sistemi in produzione ha bisogno di entrambi, ed è il secondo che le persone sottovalutano.