Por que renderizar PDF na edge importa depois de 10K faturas por dia

Se você gera algumas centenas de PDFs por dia em uma Lambda ou em um pod pequeno, a arquitetura raramente é o gargalo. Quase tudo funciona e parece rápido o bastante.

Mas quando o volume passa para dezenas de milhares de documentos por dia, como em e-commerce, logística, BNPL, folha de pagamento ou plataformas de faturamento, três números começam a pesar:

1. Latência de cold start, porque sempre existe alguma instância fria.
2. Latência regional, porque seus clientes não estão ao lado do origin.
3. Custo de computação por render, porque ele se repete milhares de vezes por dia.

É nesse ponto que renderizar no edge, como faz a gPdf, deixa de ser “a mesma coisa mais rápida” e vira outra categoria de solução.

1. O custo do cold start cresce com a concorrência

Cold start não é apenas uma requisição lenta de vez em quando. Ele acompanha sua curva de tráfego:

• Você mantém 10 contêineres aquecidos para a média.
• Um pico de 3x chega: Black Friday, dia de folha, fim de trimestre.
• 20 contêineres novos sobem para absorver o pico.
• Cada um leva 1,5 a 2,5 segundos para iniciar Chromium, Prince ou o runtime.
• Durante esses segundos, o p99 global sobe e o orçamento de timeout do pedido é gasto gerando PDF.

Em tráfego estável dá para conviver. Em tráfego de PDF, que costuma ser concentrado em ciclos de cobrança, coletas e fechamento mensal, isso vira problema operacional.

Alternativa na edge: um isolate do Cloudflare Worker inicia em 5-20 ms, não em segundos. Não há contêiner, navegador ou JVM para subir. O módulo WASM entra em um processo já vivo. Nos benchmarks da gPdf, o pior cold start observado ficou perto de 12 ms, apenas na primeira chamada de um isolate recém-criado.

2. Latência regional existe mesmo em renders rápidos

Sydney para us-east-1 já custa cerca de 200 ms antes de seu código executar. São Paulo para eu-west-1 fica perto de 190 ms. Mumbai para US East, perto de 220 ms.

Uma API PDF centralizada que renderiza em 300 ms parece assim para um usuário em Sydney:

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

Para um job em lote talvez passe. Para pré-visualizar uma fatura antes de enviar, fica perceptível.

Alternativa na edge: a Cloudflare opera em centenas de cidades. O colo perto de Sydney pode estar a 5 ms:

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

Em fluxos interativos, isso muda a experiência. E quando sua API de PDF vive no edge, lógica vizinha também pode ir para lá: autenticação, rate limit, preview no checkout. Cada peça movida reduz uma volta pela rede.

3. O custo por render cresce em silêncio

Com 100.000 renderizações por dia:

• Puppeteer com ~600 ms e 1024 MB: cerca de $240/mês só de compute, sem egress nem operação.
• DocRaptor a 89 por 100.000 páginas: cerca de **2.670/mês** para 3 milhões páginas mensais.
• gPdf a 5 por 100.000 páginas: cerca de **150/mês** para 100.000 por dia; ou $5 se seu volume mensal for 100.000.

Em 1 milhão renders por dia, a diferença aumenta:

• Puppeteer: ~$2.400/mês + operação + plantão.
• DocRaptor: ~$26.700/mês.
• gPdf: cerca de ~$1.500/mês na mesma lógica de volume.

O motivo é direto: o custo de PDF é guiado pelo footprint do renderer. Trocar um processo Chromium de centenas de MB por um módulo WASM pequeno muda a economia por página.

O que a edge realmente compra

Latência previsível sob carga

Sem custo de boot por requisição, p50 e p99 ficam próximos. Na gPdf, p99 costuma ficar dentro de 3x do p50 mesmo em pico. Com Puppeteer, tempestades de cold start podem levar p99 a 10x.

Um artefato igual em todas as regiões

Um módulo .wasm é implantado da mesma forma em cada colo da Cloudflare. Não há dúvida sobre o pool de Sydney estar aquecido nem reserva manual de concorrência regional.

Caminho para implantação embarcada

Se um cliente quiser rodar gPdf dentro da própria VPC, cluster isolado ou intranet sem saída, o mesmo WASM funciona. Não é só SaaS hospedado; é tecnologia portável.

Onde a edge não vence

• Renders de muitos segundos. Relatórios financeiros enormes ou documentos científicos de 30 segundos combinam melhor com contêineres longos.
• Renders grudados no banco. Se há JOIN pesado em OLAP, faça isso perto do banco e envie o JSON final para a edge.
• Pós-processamento com estado. Assinatura, arquivamento e watermark em múltiplas etapas podem pedir pipeline central.

Para a maioria de faturas, etiquetas e recibos B2B, a edge vence nos pontos que importam.

Quando parar de tolerar a arquitetura atual

Se três itens batem, a conta já virou:

• O custo mensal de infraestrutura PDF passa de $300.
• O p99 de PDF passa de 800 ms em tráfego normal.
• Você já teve incidente de cold start afetando clientes.
• Mais de 4 horas foram gastas com glifos CJK, RTL ou emoji.
• Você gera PDF em fluxo interativo.
• Sua operação atende mais de uma região geográfica.

Os três primeiros dizem que você paga mais e entrega pior latência. Os outros mostram que o renderer centralizado está limitando decisões de produto.

Se isso parece familiar, o Playground gera uma fatura de exemplo no navegador em menos de 5 ms.