Cloudflare Workflows: come funziona la durable execution

Un Worker riceve un’immagine, chiama un’API OCR, parsa il risultato e salva tutto nel database. Quattro operazioni in una singola richiesta sincrona. Funziona in demo, crolla in produzione. L’immagine è troppo grande, l’OCR impiega 8 secondi, il Worker va in timeout. Oppure tutto funziona tranne la scrittura nel database: il dato parsato resta in memoria e poi scompare. Nessun recovery, nessun log utile.

Cloudflare Workflows risolve esattamente questo problema. È un motore di durable execution integrato nella piattaforma Workers che permette di spezzare operazioni complesse in passaggi indipendenti, ognuno con il proprio stato persistente e la propria logica di retry. Se il passaggio 3 fallisce, il workflow riprende dal passaggio 3: i primi due non vengono rieseguiti perché il loro risultato è già salvato su disco.

Pensatelo come una catena di montaggio. Se la stazione 3 si guasta, non si smonta tutta la fabbrica: si ripara la stazione 3 e si riparte da lì. Questo principio, applicato al backend, cambia radicalmente il modo in cui si progettano workflow asincroni serverless.

Come funziona la durable execution nei Cloudflare Workflows

Il concetto di durable execution è semplice nella teoria: dopo ogni passaggio completato, il risultato viene salvato in uno storage persistente prima di passare al successivo. In pratica, questo significa che lo stato del workflow sopravvive a crash, timeout, riavvii del runtime e perfino a interruzioni prolungate.

In Cloudflare Workflows ogni passaggio è una funzione isolata. Lo stato prodotto da un passaggio fluisce automaticamente nel successivo. La piattaforma gestisce i checkpoint in modo trasparente: lo sviluppatore definisce i passaggi e la logica di retry, tutto il resto è responsabilità del motore di esecuzione.

Un dettaglio tecnico rilevante: i Workflows possono durare minuti, ore o giorni. Quando un workflow è in attesa di una risposta esterna, entra in stato di ibernazione consumando zero risorse. Questo li rende adatti sia per pipeline brevi che per processi che si estendono nel tempo, come flussi di approvazione o elaborazione documenti a lotti.

Dall’upload alla fattura: un workflow in 4 passaggi con R2, Workers AI e D1

Per capire il valore pratico, vediamo un caso d’uso concreto: un expense tracker che riceve una foto di una ricevuta, estrae i dati e li salva strutturati nel database. È l’esempio utilizzato da Cloudflare per presentare la funzionalità, e illustra perfettamente il pattern.

Passaggio 1: il Worker riceve l’immagine e la salva su R2, l’object storage di Cloudflare. A questo punto il lavoro del Worker è finito. L’immagine è al sicuro indipendentemente da cosa succede dopo.

Passaggio 2: il workflow recupera l’immagine da R2 e la invia a Workers AI per l’OCR. Qui avviene l’estrazione del testo dalla ricevuta.

Passaggio 3: l’output dell’OCR viene parsato in dati strutturati, nome del commerciante, importo totale, data della transazione.

Passaggio 4: i dati strutturati vengono scritti in D1, il database SQL di Cloudflare. La spesa è archiviata, strutturata e interrogabile.

Ogni passaggio è definito separatamente nel codice del workflow. Se il passaggio 2 (OCR) fallisce per un timeout dell’API, il workflow ritenta solo quel passaggio. L’immagine è già su R2, il passaggio 1 non viene rieseguito. Questa è la differenza fondamentale rispetto all’approccio monolitico dove un singolo errore brucia l’intera operazione.

Cosa succede quando un passaggio fallisce: retry naive vs durable

Il vero valore dei Cloudflare Workflows non emerge nel happy path. Emerge quando le cose si rompono - e in produzione si rompono sempre.

Nell’approccio tradizionale, un Worker che fa tutto in una richiesta, un fallimento a metà è un disastro silenzioso. La richiesta restituisce un errore 500, l’immagine è persa, nessun dato è stato salvato. L’utente deve ricaricare la ricevuta e sperare che funzioni al secondo tentativo.

Con i Workflows, il retry è automatico e granulare. L’immagine è ancora su R2 dal passaggio 1. Il workflow riesegue solo il passaggio fallito e la pipeline continua. L’utente non si accorge di nulla.

La configurazione del retry è per-passaggio: puoi definire il numero massimo di tentativi, il backoff tra un tentativo e l’altro, e le condizioni di fallimento definitivo. Questo livello di controllo granulare è ciò che distingue la durable execution dai retry generici a livello di richiesta HTTP.

Cloudflare Workflows vs AWS Step Functions vs Temporal nel 2026

Cloudflare Workflows non è l’unica opzione per la durable execution. Le alternative principali sono AWS Step Functions, Azure Durable Functions, Temporal e Inngest. La scelta dipende dallo stack esistente, dalla complessità dei workflow e dal livello di controllo richiesto.

Se il tuo stack è già su Cloudflare (Workers, R2, D1, Queues), i Workflows sono la scelta naturale: zero infrastruttura aggiuntiva, integrazione nativa e costi competitivi. Se dipendi dall’ecosistema AWS, Step Functions offre integrazioni più profonde con Lambda, SQS e DynamoDB. Temporal è la scelta per chi ha bisogno di orchestrazione complessa e non vuole dipendere da un cloud provider specifico, ma richiede gestione infrastrutturale o il costo di Temporal Cloud.

Una novità rilevante nel 2026: Cloudflare ha rilasciato i Dynamic Workflows, che permettono di caricare codice diverso per ogni tenant o agente AI a runtime. Questo apre scenari interessanti per chi costruisce piattaforme multi-tenant o agenti AI autonomi che necessitano di workflow personalizzati per ogni utente.

Limiti e rischi da considerare prima di adottare Cloudflare Workflows

Ogni strumento ha i suoi compromessi, e i Cloudflare Workflows non fanno eccezione.

Il primo rischio è il vendor lock-in. I Workflows sono profondamente integrati nell’ecosistema Cloudflare: R2 per lo storage, D1 per il database, Workers AI per l’inferenza. Migrare verso un altro provider significherebbe riscrivere gran parte della logica di orchestrazione. Se la portabilità è una priorità, alternative come Temporal o Inngest offrono maggiore indipendenza.

Il secondo punto è la maturità. Workflows V2 con esecuzione deterministica è stato rilasciato solo a maggio 2026. Le funzionalità avanzate sono recenti, e la community è ancora in crescita rispetto a piattaforme consolidate come AWS Step Functions. La documentazione e i pattern di uso avanzato sono meno rodati.

Terzo punto: non tutto dovrebbe essere un workflow. Per operazioni semplici che completano in pochi millisecondi, l’overhead della persistenza dello stato è inutile. I Workflows brillano quando hai 3 o più passaggi indipendenti, ognuno con probabilità di fallimento diversa. Per una singola chiamata API con retry, un semplice try/catch con backoff è sufficiente.

Infine, una domanda aperta: con i Dynamic Workflows che eseguono codice diverso per ogni tenant a runtime, come si gestisce la sicurezza e l’isolamento in scenari complessi? Cloudflare fornisce isolamento a livello di Worker, ma i pattern per validare e sandboxare codice generato dinamicamente - specialmente nel contesto di agenti AI autonomi - sono ancora in fase di definizione.

Oltre l’expense tracker: dove la durable execution fa la differenza

Il pattern dei workflow durabili va ben oltre il tracciamento spese. Pipeline di moderazione immagini, flussi di onboarding multi-step, elaborazione documenti a catena, generazione e post-processing di contenuti con modelli AI: ovunque ci sia una sequenza di operazioni che deve essere affidabile ad ogni passaggio, la durable execution è il pattern corretto.

La vera domanda per chi costruisce backend nel 2026 non è se adottare la durable execution, ma quando. I workflow monolitici che gestiscono tutto in una singola richiesta sincrona sono un pattern che funziona in demo ma tradisce in produzione. Gli strumenti per fare meglio esistono già, e la barriera d’ingresso è più bassa che mai. Resta da capire quanto tempo ci vorrà prima che diventi lo standard, non l’eccezione.