Cloudflare Queues: Job in Background All'edge

Cloudflare Queues risolve il problema in cui prima o poi finisce ogni applicazione serverless: arriva una richiesta che innesca un lavoro che l’utente non dovrebbe dover aspettare. Inviare l’email di conferma, ridimensionare il file caricato, sincronizzare il record verso un servizio esterno. Su un server tradizionale quel lavoro lo passate a un processo in background. Su Workers non esiste alcun processo a cui passarlo.

Le soluzioni di ripiego più comuni sono peggiori di quanto sembrino. Fare il lavoro in linea costringe l’utente ad aspettare un provider di posta. Lanciare una richiesta verso un altro Worker senza attenderla perde il job ogni volta che l’invocazione chiamante termina per prima. Nessuna delle due sopravvive a un guasto del provider.

Cosa vi dà davvero una coda: durabilità e nuovi tentativi, non velocità. Il producer scrive un messaggio e ritorna subito, un Worker consumer separato lo raccoglie, e se il consumer fallisce il messaggio torna in coda invece di sparire nel nulla. Il valore è tutto qui. Se il vostro job in background non tollera di essere rieseguito, una coda non vi salverà.

Come si incastrano i pezzi

Una coda ha due estremità ed entrambe sono Workers.

Il producer è un qualsiasi Worker con un binding di coda. Chiama send con un corpo del messaggio, e quella chiamata ritorna non appena il messaggio è memorizzato in modo durevole. La richiesta dell’utente si chiude senza attendere il lavoro.

Il consumer è un Worker con un handler di coda. Cloudflare lo invoca con un batch di messaggi, e l’handler conferma ogni messaggio che elabora con successo. Tutto ciò che non viene confermato viene riconsegnato.

Il comportamento di riconsegna è la parte attorno a cui va progettato il resto. Un messaggio può arrivare più di una volta, quindi il vostro consumer deve essere idempotente. Addebitare una carta dentro un consumer di coda senza una chiave di idempotenza è il modo sicuro per finire a rimborsare le persone. Mandare due volte un’email è fastidioso, incassare due volte è un incidente di supporto.

Una dead letter queue raccoglie i messaggi che falliscono ripetutamente. Senza di essa un messaggio irrimediabilmente rotto viene ritentato finché non esaurisce i tentativi, poi svanisce. Con essa finisce in un posto dove potete ispezionarlo. Configuratela prima di averne bisogno.

Quanto costa davvero un’operazione

Il modello di prezzo è abbastanza insolito da far inciampare i team, perché la fatturazione non avviene per messaggio.

Un’operazione viene conteggiata ogni 64 KB di dati scritti, letti o cancellati. Un messaggio sotto i 64 KB consegnato normalmente costa tre operazioni: una scrittura, una lettura, una cancellazione. Un messaggio da 127 KB costa due operazioni per azione, quindi sei in totale per quella stessa singola consegna.

I nuovi tentativi cambiano i conti. Ogni riconsegna è un’altra lettura, e una scrittura nella dead letter queue è un’altra scrittura. Un consumer che fallisce cinque volte su un messaggio prima di riuscire costa molto più di tre operazioni, ed è una buona ragione per riparare un consumer instabile invece di alzargli il numero di tentativi.

Fate i conti sul vostro traffico prima di dare per scontato che sia economico. Un milione di messaggi al mese a tre operazioni ciascuno fanno tre milioni di operazioni, che superano la soglia inclusa nel piano a pagamento e costano circa ottanta penny. Questo è davvero poco. Dieci milioni di messaggi al giorno sono un discorso diverso.

I limiti che decidono se fa al caso vostro

Dalla documentazione sui limiti di Queues di Cloudflare, verificata ad agosto 2026.

Due di questi contano più degli altri. Il tetto di 128 KB per messaggio significa che nella coda non ci mettete file. Ci mettete un puntatore e il file lo mettete in R2, che è comunque la forma giusta. Il backlog da 25 GB è ciò che vi protegge dal disastro silenzioso: se il consumer si rompe di venerdì e nessuno se ne accorge, la coda si riempie e poi rifiuta i nuovi messaggi con un errore di storage, invece di scartarli in silenzio.

Il throughput di 5.000 messaggi al secondo è generoso, ma vale per singola coda. Una sola coda molto sollecitata è un collo di bottiglia che potete eliminare in fase di progetto distribuendo il carico su più code.

Quando Cloudflare Queues è la risposta sbagliata

Quando il lavoro è davvero sincrono. Se l’utente ha bisogno del risultato a schermo, metterlo in coda aggiunge solo un giro in più e un problema di polling. Fatelo in linea e fatelo veloce.

Quando vi serve un’elaborazione ordinata ed exactly-once. Queues offre consegna at-least-once. Tutto ciò che richiede un ordine rigoroso o una semantica exactly-once richiede un coordinamento che la coda non fornisce, e su Cloudflare di solito significa un Durable Object.

Quando è un job pianificato e non innescato. Una pulizia notturna non ha bisogno di una coda. Un cron trigger che invoca direttamente un Worker è più semplice e ha meno parti in movimento.

Quando il lavoro supera i 15 minuti. Un consumer che va oltre il proprio limite di esecuzione viene terminato a metà lavoro. I processi lunghi in più passaggi vogliono Cloudflare Workflows, che è pensato per l’esecuzione durevole attraverso più step, non un consumer di coda che prova a tenere lo stato per un quarto d’ora.

La nostra guida su come costruire una API serverless con Cloudflare Workers copre il percorso di richiesta che di solito genera questi job, e Cloudflare Workers contro AWS Lambda spiega come il modello di esecuzione differisca dallo schema SQS più Lambda con cui arriva la maggior parte dei team.

Da dove iniziare

Scegliete l’unico pezzo di lavoro nel vostro request handler che l’utente non ha bisogno di aspettare, e spostate solo quello. Dategli una dead letter queue dal primo giorno, rendete il consumer idempotente, e guardate la metrica del backlog invece di dare per scontato che sia vuoto.

Mecanik progetta e verifica architetture edge attraverso il nostro team di sviluppo software , inclusa la parte in cui qualcuno chiede se quel job abbia davvero bisogno di una coda. La maggior parte dei sistemi ne vuole una o due, non una per funzionalità.

Da leggere anche: Cloudflare Hyperdrive: Postgres dall’edge , Come sviluppare una web app nel 2026: guida UK , Cloudflare D1: creare un database SQL serverless all’edge e Cloudflare Workers AI: eseguire modelli IA all’edge nel 2026 .

Domande frequenti

Quanto costa Cloudflare Queues? Il piano Workers Free include 10.000 operazioni al giorno e il piano Paid un milione di operazioni al mese, le operazioni aggiuntive costano 0,40 $ per milione e non ci sono costi di egress. Un’operazione viene conteggiata ogni 64 KB scritti, letti o cancellati, quindi un messaggio normale sotto i 64 KB costa in totale tre operazioni: una scrittura, una lettura e una cancellazione.

Che cosa conta come operazione in Cloudflare Queues? Ogni 64 KB di dati scritti, letti o cancellati. Un messaggio più piccolo di 64 KB costa un’operazione per azione, mentre un messaggio da 127 KB ne costa due per azione. Ogni nuovo tentativo aggiunge un’altra lettura e una scrittura nella dead letter queue aggiunge un’altra scrittura, quindi un consumer instabile costa molto più delle tre operazioni di base per messaggio.

Qual è la dimensione massima di un messaggio in Cloudflare Queues? 128 KB per messaggio, con gli invii in batch limitati a 100 messaggi o 256 KB totali. Per via di quel tetto conviene salvare il payload in R2 o in un altro object store e mettere in coda soltanto un puntatore, che resta il progetto migliore a prescindere dal limite.

Cloudflare Queues garantisce la consegna exactly-once? No. La consegna è at-least-once, quindi un messaggio può arrivare più di una volta e il vostro consumer deve essere idempotente. Addebitare un pagamento o emettere un credito dentro un consumer senza chiave di idempotenza prima o poi produrrà un doppione. Un ordine rigoroso o una semantica exactly-once richiedono invece un Durable Object.

Quando non conviene usare Cloudflare Queues? Quando l’utente sta aspettando il risultato, quando vi serve un ordine rigoroso o un’elaborazione exactly-once, quando il job è pianificato invece che innescato e basterebbe un cron trigger, oppure quando il lavoro dura più del limite di 15 minuti del consumer. Proprio per quest’ultimo caso esiste Cloudflare Workflows.