A carga de trabalho de etiquetas de envio, em um parágrafo
Cada pedido produz um PDF, cada PDF é impresso uma vez em uma impressora térmica, e o modo de falha quando você é lento não é “a página carrega devagar” — é “a coleta do armazém ficou esperando atrás da sua API de renderização de etiquetas”. Envio é uma carga em que a latência p99 é a métrica do produto, em que saída determinística importa porque reimpressões são rotina, e em que qualidade de código de barras — medida nas tolerâncias de X-dimension da GS1, não em pixels — decide se os scanners leem a etiqueta na primeira passagem.
Stacks de PDF baseadas em navegador headless têm dificuldade nos três pontos ao mesmo tempo: o custo de cold start se acumula durante picos, códigos de barras rasterizados degradam em etiquetas térmicas pequenas, e a rasterização de fontes muda entre versões do Chromium, tornando impossível uma reimpressão byte a byte idêntica.
Por que gPdf se encaixa
Uma etiqueta térmica 4×6 é pequena (576 × 864 pixels a 203 dpi), tem poucos elementos (blocos de texto + 1-2 códigos de barras + um logotipo opcional da transportadora) e alto volume (um 3PL de médio porte renderiza 50 mil a 500 mil por dia). Essa é a carga de trabalho para a qual o gPdf foi criado. O renderizador:
- Compila o layout uma vez — coordenadas de página, cascatas de fontes e geometria de códigos de barras são resolvidas no momento da requisição, não por um mecanismo de layout de navegador.
- Vetoriza cada código de barras — os módulos são desenhados diretamente no stream do PDF, então um GS1-128 de 30 mm de largura é lido com nitidez a 203 dpi ou 600 dpi sem lógica de rasterização sensível a DPI no seu lado.
- Incorpora NotoSans CJK + Latin — os mesmos dados renderizam corretamente o nome de uma transportadora em chinês sem que você provisione fontes em um contêiner de renderização.
O p99 fica plano em 8 ms na nossa carga de referência (1.000 invocações do exemplo acima em EU-WEST), independentemente de um isolate ter renderizado uma etiqueta ou 10 mil etiquetas.
Volume + cálculo de custo
Um 3PL típico de médio porte opera em torno de 50 mil etiquetas/dia = ~1,5 milhão/mês. No plano Basic (US 5/mês por 100 mil páginas, US 0,00005 por página excedente), isso fica assim:
1,5 milhão de páginas × US$ 0,00005 = US$ 75,00 em excedente
+ base do plano Basic = US$ 5,00
────────────────────────────────────────────────────
total = US$ 80,00 / mês
A mesma carga em Puppeteer-on-Lambda fica na faixa de US$ 200-400/mês com configurações típicas de concorrência em Lambda, antes de considerar o custo de cold start nos horários de pico.
Black Friday: um exemplo calculado
O pico é a carga em que a renderização na edge mostra mais claramente seu valor. Um varejista que chega a 200% do volume normal de etiquetas na primeira hora da Black Friday — digamos 100 mil etiquetas em 60 minutos, média de 1,7 mil etiquetas/minuto com rajadas de pico de 5 mil/minuto — conclui tudo dentro de um único pool regional do Cloudflare Workers, sem custo de cold start. A mesma carga em um warm pool de Puppeteer dimensionado para o tráfego médio gera cold starts de 1,5-2,5 s nos contêineres criados para a rajada, e a mesa de coleta do armazém sente cada um deles.
Para onde olhar agora
- A JSON Render API cobre todos os campos usados no exemplo de etiqueta acima.
- Para a explicação mais profunda sobre geometria de códigos de barras, leia o post sobre precisão GS1-128.
- Substituindo um pipeline de etiquetas em iText? Veja gPdf vs iText para etiquetas logísticas ou a análise completa de TCO de etiquetas de envio de 100 mil a 100 milhões de páginas/mês.
- Para comparar com uma stack baseada em Chromium, veja gPdf vs Puppeteer.