Se renderizzate qualche centinaio di PDF al giorno su una Lambda backend o su un piccolo pod Kubernetes, l’architettura non conta davvero. Funziona tutto. Tutto è abbastanza veloce.

Le cose cambiano in scala. Quando emettete decine di migliaia di documenti al giorno, cioè più o meno qualsiasi piattaforma ecommerce, corriere logistico, servizio BNPL, provider payroll o piattaforma di fatturazione con una trazione anche moderata, tre numeri iniziano a fare male:

Latenza di cold start, perché da qualche parte c’è sempre qualcosa di freddo.
Latenza regionale, perché i vostri clienti non sono accanto al vostro origin.
Compute per rendering, perché lo pagate decine di migliaia di volte al giorno.

Questo articolo mostra come ciascuno di questi numeri cambia oltre circa 10K rendering/giorno, e perché motori distribuiti all’edge come gPdf sono sostanzialmente una categoria diversa di soluzione, non “la stessa cosa, solo più veloce”.

1. La tassa di cold start cresce con la concorrenza

I cold start non sono solo un fastidio: sono una funzione della vostra curva di concorrenza. Di solito succede così:

Provisionate N=10 container caldi sulla base del traffico medio.
Arriva un picco 3× (Black Friday, giorno payroll, fine trimestre).
20 nuovi container partono a freddo per assorbire il picco. Ognuno impiega 1,5-2,5 secondi ad avviare Chromium / Prince / il vostro runtime.
Per quei 30 secondi, i nuovi container servono a p99 = 2 secondi, trascinando con sé il p99 globale.
Il budget di timeout a valle (probabilmente 5-10 s per l’intera pipeline ordine) viene consumato dalla generazione PDF.

Va bene quando il traffico è piatto. È brutale quando il traffico ha picchi, e il traffico PDF ha sempre picchi: le fatture partono ai confini dei cicli di billing, le etichette partono quando i corrieri ritirano, gli estratti conto partono a fine mese.

Alternativa edge: un isolate Cloudflare Worker cold-starta in 5-20 ms, non in 1,5-2,5 secondi. Non c’è container da avviare, nessuna JVM/V8 da inizializzare, nessun browser da bootstrap: il modulo WASM viene caricato in un processo già vivo. Il cold start smette di essere una cosa attorno a cui progettare l’architettura.

Per gPdf nello specifico, il peggior cold start osservato nei nostri benchmark è circa 12 ms, e solo per la prima richiesta a un isolate appena assegnato. Le richieste successive sullo stesso isolate saltano anche quello.

2. La latenza regionale è reale, anche per richieste “veloci”

Il round-trip da Sydney a un origin us-east-1 è 200 ms prima che il vostro codice faccia qualsiasi cosa. Da São Paulo a eu-west-1, circa 190 ms. Da Mumbai a US East, circa 220 ms.

È per direzione. Quindi una API PDF centralizzata che fa un rendering server-side da 300 ms, vista da un cliente a Sydney, appare così:

client -> us-east  : 200 ms
us-east render     : 300 ms
us-east -> client  : 200 ms
total wall-clock   : 700 ms

Per un flusso interattivo (“mostrami l’anteprima della fattura prima di inviarla”) è doloroso. Per un job backend ad alto volume non si nota.

Alternativa edge: Cloudflare gira in oltre 300 città. Il colo più vicino al cliente di Sydney è a circa 5 ms. Lo stesso rendering diventa:

client -> SYD colo : 5 ms
SYD render         : 4 ms
SYD -> client      : 5 ms
total wall-clock   : 14 ms

È un miglioramento 50× per i flussi interattivi. Per i job backend è neutro, ma le anteprime PDF interattive (“fammi vedere come appare prima di inviare”) diventano libere invece che scattose.

Il secondo beneficio, meno visibile: se la vostra API PDF gira all’edge, potete spostare lì anche logica adiacente: anteprima PDF in checkout, rate limit, controllo auth. Ogni pezzo spinto all’edge toglie un round-trip dal percorso critico.

3. Il compute per rendering è la fattura che cresce in silenzio

Matematica Lambda a 100K rendering/giorno:

Puppeteer a circa 600 ms wall, 1024 MB di memoria: circa 240 USD/mese solo di compute, prima dell’egress.
DocRaptor al tier 89 USD/100K pagine: circa 2.670 USD/mese a 100K/giorno (= 3M/mese).
gPdf al tier 5 USD/100K pagine: circa 150 USD/mese a 100K/giorno. Oppure circa 5 USD/mese se finite esattamente a 100K/mese.

Il divario di costo non sparisce quando scalate, aumenta. A 1M rendering/giorno:

Puppeteer infra: circa 2.400 USD/mese + ops + reperibilità
DocRaptor: circa 26.700 USD/mese
gPdf: 1.500 USD/mese flat (5× del tier da 100K/giorno, assumendo volume negoziato sulla griglia pubblica)

Reazione comune: “Sicuramente nella pratica il risparmio è minore: ci sarà qualcosa di nascosto.” Nella nostra esperienza, no. Il driver di costo nella generazione PDF è il footprint computazionale del motore. Quando sostituite un processo Chromium da 600 MB con un modulo WASM da 4 MB, il costo per rendering scende di circa 100×, e la fattura segue.

Il motivo per cui funziona senza mandarci in perdita: il prezzo sottostante di Cloudflare Workers Bundled è circa 0,50 USD/milione di richieste. Con il nostro motore che usa circa 1,5 ms di CPU per chiamata, il costo del venduto per rendering è davvero sotto il centesimo. Lo ricarichiamo in modo moderato per costruire un business sostenibile e voi vedete comunque il divario 18×.

Cosa compra davvero “edge-deployed”

Tre cose, nessuna legata alle slide marketing:

Latenza prevedibile sotto qualsiasi carico

Poiché non c’è costo di avvio per richiesta, p50 e p99 restano vicini. Tipicamente vediamo p99 entro 3× del p50 anche al culmine di un picco di traffico, contro Puppeteer dove p99 può arrivare a 10× p50 durante tempeste di cold start.

Un singolo artifact distribuibile ovunque

Un modulo .wasm viene distribuito in modo identico in ogni colo Cloudflare. Non c’è la domanda “il pool di Sydney è caldo?”: ogni isolate avvia il modulo in millisecondi e serve allo stesso modo. Operativamente è davvero più semplice che mantenere prenotazioni di concorrenza Lambda per regione.

Una strada verso l’embedding

Se un giorno volete eseguire gPdf dentro il perimetro di un cliente (la sua VPC, il suo cluster isolato, la sua intranet air-gapped), lo stesso modulo WASM funziona. È la differenza tra “abbiamo ospitato un SaaS” e “abbiamo consegnato tecnologia che gira ovunque”.

Dove questo approccio si rompe

L’edge non è magia gratis: ci sono carichi in cui vince il centralizzato.

Rendering da molti secondi. Se un singolo PDF richiede 30 secondi (enormi rendiconti finanziari, report scientifici), è meglio un container long-running con stato persistente che combattere i limiti CPU all’edge.
Rendering che richiede altri database. Se il rendering deve fare JOIN su tre tabelle OLAP, volete il motore vicino al database, non all’edge. Soluzione: fate la JOIN, poi inviate il JSON all’edge per il rendering vero e proprio.
Output che richiede post-processing. Watermark, firme, archiviazione: se la pipeline post-rendering è multi-step e stateful, la proprietà stateless del rendering edge diventa una tassa invece che un vantaggio.

Per tutto il resto, cioè la grande maggioranza del traffico B2B di fatture, etichette e ricevute, l’edge vince sugli assi che contano.

Quando smettere di tollerare il setup attuale

Checklist semplice. Se potete spuntarne tre, la matematica della migrazione ha già cambiato segno:

Il costo mensile dell’infrastruttura PDF supera 300 USD.
La latenza p99 dei PDF supera 800 ms durante traffico normale.
Avete avuto un incidente di cold start visibile ai clienti.
Avete speso più di 4 ore a debuggare glifi CJK / RTL / emoji mancanti.
Generate PDF in un flusso interattivo (anteprima, download a schermo).
Operate in più di una regione geografica.

I primi tre elementi insieme significano che state pagando e soffrendo. Gli altri tre significano che un motore centralizzato sta limitando decisioni di prodotto che potreste altrimenti prendere.

Se qualcosa suona familiare, il Playground renderizza una fattura di esempio nel browser in meno di 5 ms: lasciatelo parlare.