Blog

Mengapa edge PDF rendering penting setelah 10K invoice per hari

Cold start, latency regional, dan biaya per halaman berubah saat volume naik. Panduan praktis kapan edge rendering mulai memberi dampak nyata.

Jika Anda membuat beberapa ratus PDF per hari dari satu Lambda atau pod Kubernetes kecil, arsitektur jarang terasa penting. Hampir semua pilihan bekerja dan tampak cukup cepat.

Masalah muncul ketika volume naik ke puluhan ribu dokumen per hari: invoice e-commerce, label logistik, receipt BNPL, payroll slip, atau platform billing. Pada titik itu, tiga angka mulai terasa:

  1. Cold-start latency, karena selalu ada instance atau region yang dingin.
  2. Regional latency, karena pengguna tidak selalu dekat dengan origin.
  3. Per-render compute, karena biaya kecil itu dibayar puluhan ribu kali sehari.

Edge-deployed renderer seperti gPdf mengubah hitungan ini, bukan sekadar membuat server PDF biasa sedikit lebih cepat.

1. Cold start mengikuti kurva concurrency

Polanya sering sama. Anda menyiapkan 10 container hangat untuk traffic rata-rata. Lalu ada spike 3x pada Black Friday, akhir bulan, atau hari payroll. Dua puluh container baru cold-start untuk menyerap spike, masing-masing butuh 1,5-2,5 detik untuk menyalakan Chromium, Prince, atau runtime.

Selama puluhan detik itu, p99 global ikut naik. Timeout budget checkout, order pipeline, atau workflow invoice habis untuk PDF generation.

Traffic PDF juga jarang rata. Invoice muncul di akhir siklus billing, label saat pickup carrier, statement di akhir bulan.

Alternatif edge: Cloudflare Worker isolate cold-start dalam 5-20 ms, bukan detik. Tidak ada container atau browser yang harus dinyalakan; WASM module masuk ke process yang sudah hidup. Pada benchmark gPdf, worst cold start sekitar 12 ms dan hanya terjadi pada request pertama isolate baru.

2. Latency regional tetap ada walau render cepat

Dari Sydney ke us-east-1, round-trip sudah sekitar 200 ms sebelum kode Anda berjalan. São Paulo ke eu-west-1 sekitar 190 ms. Mumbai ke US East sekitar 220 ms.

API PDF terpusat dengan render 300 ms akan terasa seperti ini:

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

Untuk batch job, ini mungkin diterima. Untuk preview invoice interaktif, pengguna merasakan lambat.

Alternatif edge: Cloudflare berjalan di ratusan kota. Colo terdekat dari Sydney bisa hanya beberapa ms.

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

Efek tambahannya: auth check, rate limit, dan preview checkout bisa ikut dipindahkan mendekati pengguna, sehingga hot path kehilangan round-trip yang tidak perlu.

3. Biaya per render menumpuk diam-diam

Contoh 100.000 render per hari:

  • Puppeteer sekitar 600 ms dan 1024 MB: kira-kira $240/bulan hanya compute.
  • DocRaptor pada 89/100.000 halaman: sekitar **2.670/bulan** untuk 3 juta halaman.
  • gPdf pada 5/100.000 halaman: sekitar **150/bulan** untuk 100.000 per hari, atau $5 bila volume bulanan tepat 100.000.

Pada 1 juta renders per hari, gap makin besar: Puppeteer sekitar 2.400/bulan plus operasi, DocRaptor sekitar 26.700/bulan, dan gPdf sekitar $1.500/bulan dalam logika volume yang sama.

Penyebabnya sederhana: footprint renderer menentukan biaya. Mengganti proses Chromium ratusan MB dengan WASM module beberapa MB membuat unit economics berubah permanen.

Apa yang benar-benar dibeli oleh edge

Latency yang lebih mudah diprediksi

Tanpa biaya boot per request, p50 dan p99 tetap dekat. gPdf biasanya melihat p99 dalam 3x p50 bahkan saat spike; Puppeteer bisa melebar sampai 10x saat cold-start storm.

Artefak deploy yang sama di semua lokasi

.wasm module didistribusikan sama ke setiap Cloudflare colo. Tidak ada pertanyaan apakah pool Sydney sudah warm.

Jalur menuju deployment embedded

Jika pelanggan ingin menjalankan gPdf di VPC, cluster tertutup, atau intranet mereka, module WASM yang sama tetap dapat dipakai. Ini bukan hanya SaaS yang di-host, tetapi teknologi yang portable.

Kapan edge bukan jawaban terbaik

  • Render multi-detik: report finansial besar 30 detik lebih cocok di long-running container.
  • Render yang menempel ke database: JOIN OLAP berat sebaiknya dilakukan dekat database, lalu JSON final dikirim ke edge.
  • Post-processing stateful: signing, archival, dan watermark pipeline kompleks mungkin lebih cocok di workflow pusat.

Untuk mayoritas invoice, label, dan receipt B2B, edge menang pada axis yang paling terasa: latency, biaya, dan operasi.

Kapan berhenti menoleransi setup lama

Jika tiga poin ini benar, migrasi sudah layak diuji:

  • Biaya infrastruktur PDF melewati $300/bulan.
  • p99 PDF melebihi 800 ms pada traffic normal.
  • Anda pernah mengalami cold-start incident yang terlihat oleh pelanggan.
  • Anda menghabiskan lebih dari 4 jam mengejar glyph CJK, RTL, atau emoji.
  • PDF dibuat dalam flow interaktif seperti preview atau download di layar.
  • Anda beroperasi di lebih dari satu region.

Jika terdengar familier, Playground dapat merender sample invoice dalam browser dalam hitungan ms.