Si genera unos cientos de PDF al día desde una Lambda de backend o un pod pequeño de Kubernetes, la arquitectura no decide realmente el resultado. Casi cualquier cosa funciona. Casi cualquier cosa es suficientemente rápida.

Las cosas cambian a escala. Cuando emite decenas de miles de documentos al día — aproximadamente cualquier plataforma de comercio electrónico, operador logístico, servicio BNPL, proveedor de nóminas o plataforma de facturación con una tracción modesta — tres números empiezan a doler:

Latencia de arranque en frío, porque siempre hay algo frío en alguna parte.
Latencia regional, porque sus clientes no viven junto a su origen.
Cómputo por renderizado, porque lo paga decenas de miles de veces al día.

Este artículo recorre cómo cambia cada uno de esos números a partir de unos 10.000 renderizados diarios, y por qué los renderizadores desplegados en el edge, como gPdf, son básicamente otra categoría de solución, no “lo mismo, pero más rápido”.

1. El impuesto del arranque en frío crece con la concurrencia

Los arranques en frío no son solo una molestia: son una función de su curva de concurrencia. El patrón habitual:

Aprovisiona N=10 contenedores calientes según el tráfico medio.
Llega un pico de tráfico de 3× (Black Friday, día de nómina, cierre de trimestre).
Arrancan en frío 20 contenedores nuevos para absorber el pico. Cada uno tarda 1,5-2,5 segundos en iniciar Chromium, Prince o su entorno de ejecución.
Durante esos 30 segundos, los contenedores nuevos sirven con p99 = 2 segundos y arrastran el p99 global.
Su presupuesto de timeout aguas abajo (probablemente 5-10 s para todo el flujo de pedido) queda consumido por la generación de PDF.

Esto se tolera cuando el tráfico es plano. Es brutal cuando el tráfico tiene picos, y el tráfico PDF siempre tiene picos: las facturas salen en los cierres de ciclo de facturación, las etiquetas salen cuando los transportistas recogen y los extractos salen a fin de mes.

Alternativa en el edge: un isolate de Cloudflare Worker arranca en 5-20 ms, no en 1,5-2,5 segundos. No hay contenedor que levantar, ni JVM/V8 que inicializar, ni navegador que arrancar: el módulo WASM se carga dentro de un proceso que ya está vivo. El arranque en frío deja de ser algo alrededor de lo cual tenga que diseñar la arquitectura.

En gPdf, el peor arranque en frío observado en nuestras mediciones ronda los 12 ms, y solo afecta a la primera petición de un isolate recién asignado. Las siguientes peticiones en el mismo isolate omiten incluso eso.

2. La latencia regional no desaparece aunque el renderizado sea rápido

Un ida y vuelta de Sídney a un origen en us-east-1 ya cuesta unos 200 ms antes de que su código haga nada. De São Paulo a eu-west-1, unos 190 ms. De Mumbai a la costa este de EE. UU., unos 220 ms.

Eso ocurre en cada dirección. Por eso una API PDF centralizada que hace un renderizado de servidor de 300 ms se ve así desde la perspectiva de un cliente en Sídney:

cliente -> us-east  : 200 ms
renderizado us-east : 300 ms
us-east -> cliente  : 200 ms
tiempo total        : 700 ms

Para un flujo interactivo (“previsualice su factura antes de enviarla”), duele. Para un trabajo backend de alto volumen, casi no se nota.

Alternativa en el edge: Cloudflare opera en más de 300 ciudades. El colo más cercano a su cliente en Sídney está aproximadamente a 5 ms:

cliente -> SYD colo : 5 ms
renderizado SYD     : 4 ms
SYD -> cliente      : 5 ms
tiempo total        : 14 ms

Eso es una mejora de 50× en flujos interactivos. En trabajos backend puede quedar empatado, pero las previsualizaciones PDF interactivas (“muéstreme cómo quedará antes de enviarlo”) pasan de sentirse torpes a sentirse gratis.

El beneficio oculto de segundo orden: si su API PDF corre en el edge, también puede mover allí lógica adyacente: la previsualización PDF del checkout, el rate limit, la comprobación de autenticación. Cada pieza que empuja al edge elimina un ida y vuelta del camino caliente.

3. El coste por renderizado se acumula en silencio

Matemática de precios de Lambda con 100.000 renderizados al día:

Puppeteer con ~600 ms de tiempo total y 1024 MB de memoria: unos 240 USD/mes solo en cómputo, antes de egreso.
DocRaptor en el tramo de 89 USD por 100.000 páginas: unos 2.670 USD/mes con 100.000/día (= 3 millones/mes).
gPdf en el tramo de 5 USD por 100.000 páginas: unos 150 USD/mes con 100.000/día. O unos 5 USD/mes si justo cae en 100.000/mes.

La brecha de coste no desaparece al escalar: se amplía. Con 1 millón de renderizados al día:

Puppeteer infra: unos 2.400 USD/mes + operación + guardias.
DocRaptor: unos 26.700 USD/mes.
gPdf: 1.500 USD/mes plano (5× el tramo de 100.000/día, suponiendo negociación de volumen sobre la tabla pública).

Una reacción común es: “Seguro que el ahorro es menor en la práctica; algo habrá escondido.” En nuestra experiencia, no. El coste de generar PDF lo marca la huella de cómputo del renderizador. Al cambiar un proceso Chromium de 600 MB por un módulo WASM de 4 MB, el coste por renderizado cae aproximadamente 100×, y la factura lo sigue.

La razón por la que esto funciona sin que nos arruine: el precio subyacente de Cloudflare Workers Bundled ronda los 0,50 USD por millón de solicitudes. Con nuestro renderizador usando aproximadamente 1,5 ms de CPU por llamada, el coste de bienes vendidos por renderizado es realmente inferior a un céntimo. Añadimos un margen moderado para sostener el negocio y aun así usted ve la brecha de 18×.

Qué compra realmente el edge

Tres cosas, ninguna de marketing:

Latencia predecible bajo carga

Sin coste de arranque por petición, p50 y p99 se mantienen cerca. En gPdf solemos ver p99 dentro de 3× del p50 incluso en picos; con Puppeteer, las tormentas de arranques en frío pueden llevar el p99 a 10×.

Un artefacto desplegable en todas partes

Un módulo .wasm se despliega de forma idéntica en cada colo de Cloudflare. No existe la pregunta “¿está caliente el pool de Sídney?”: cada isolate arranca el módulo en milisegundos y sirve igual. Operativamente, esto es realmente más simple que mantener reservas regionales de concurrencia en Lambda.

Una ruta hacia despliegues embebidos

Si algún día quiere ejecutar gPdf dentro del perímetro de un cliente (su VPC, su clúster aislado, su intranet desconectada), el mismo módulo WASM funciona. Es la diferencia entre “alojamos un SaaS” y “enviamos tecnología que corre en cualquier sitio”.

Dónde el edge no es la mejor respuesta

Renderizados de muchos segundos. Si un solo PDF tarda 30 segundos (estados financieros enormes, informes científicos), conviene más un contenedor de larga ejecución con estado persistente que pelear con límites de CPU en el edge.
Renderizados que necesitan otras bases de datos. Si su renderizado necesita hacer JOIN de tres tablas OLAP, conviene tener el renderizador junto a la base, no en el edge. Solución: haga el JOIN y luego envíe el JSON al edge para el renderizado real.
Salidas que necesitan posprocesado. Marca de agua, firma, archivado: si su proceso posterior al renderizado tiene varios pasos y estado, la propiedad “sin estado” del renderizado en el edge se convierte en un coste en vez de una ventaja.

Para todo lo demás — y eso es la gran mayoría del tráfico B2B de facturas, etiquetas y recibos — el edge gana en todos los ejes que importan.

Cuándo dejar de tolerar su arquitectura actual

Si marca tres puntos, la migración ya merece una prueba seria:

Su coste mensual de infraestructura PDF supera 300 USD.
El p99 de PDF pasa de 800 ms con tráfico normal.
Ya tuvo un incidente de arranque en frío visible para clientes.
Ha perdido más de 4 horas con glifos CJK, RTL o emoji.
Genera PDF en un flujo interactivo (previsualización, descarga en pantalla).
Opera en más de una región geográfica.

Los tres primeros significan que paga y sufre. Los tres últimos significan que un renderizador centralizado limita activamente decisiones de producto que podría tomar de otra manera.

Si algo de esto le resulta familiar, el Playground genera una factura de ejemplo en su navegador en menos de 5 ms: deje que el resultado hable por sí mismo.