ทำไม edge PDF rendering สำคัญเมื่อเกิน 10K invoice ต่อวัน

ถ้าคุณสร้าง PDF วันละไม่กี่ร้อยไฟล์จาก Lambda เดียวหรือ Kubernetes pod เล็ก ๆ architecture อาจไม่ใช่เรื่องใหญ่ วิธีส่วนใหญ่ทำงานได้และเร็วพอ

แต่เมื่อ volume ขึ้นไปถึงหลักหลายหมื่นเอกสารต่อวัน เช่น invoice ของ e-commerce, shipping label, receipt ของ BNPL, payslip หรือ billing platform ตัวเลขสามตัวจะเริ่มกดดันระบบ:

1. Cold-start latency เพราะมี instance หรือ region ที่เย็นอยู่เสมอ
2. Regional latency เพราะผู้ใช้ไม่ได้อยู่ใกล้ origin ของคุณ
3. Per-render compute เพราะคุณจ่ายต้นทุนนี้ซ้ำหลายหมื่นครั้งต่อวัน

Renderer ที่ deploy บน edge อย่าง gPdf ไม่ได้แค่ทำให้ server PDF เดิมเร็วขึ้น แต่เปลี่ยนสมการ latency และ cost ไปเลย

1. Cold start โตตาม concurrency

รูปแบบที่เจอบ่อยคือคุณเตรียม warm container 10 ตัวสำหรับ traffic เฉลี่ย แล้วมี spike 3x ใน Black Friday, สิ้นเดือน หรือวันจ่ายเงินเดือน ระบบต้องเปิด container ใหม่ 20 ตัว แต่ละตัวใช้ 1.5-2.5 วินาทีในการ boot Chromium, Prince หรือ runtime ช่วงนั้น p99 ทั่วระบบจะสูงขึ้นทันที

PDF traffic มักมาเป็นก้อนอยู่แล้ว invoice มาตาม billing cycle, label มาตอน carrier pickup, statement มาสิ้นเดือน

ทางเลือกบน edge: Cloudflare Worker isolate cold-start ใน 5-20 ms ไม่ใช่วินาที ไม่มี container หรือ browser ให้ boot; WASM module โหลดเข้า process ที่ทำงานอยู่แล้ว ใน benchmark ของ gPdf worst cold start ประมาณ 12 ms และเกิดเฉพาะ request แรกของ isolate ใหม่

2. Regional latency ยังมีอยู่แม้ render เร็ว

จาก Sydney ไป us-east-1 มี latency ประมาณ 200 ms ก่อน code จะเริ่มทำงาน São Paulo ไป eu-west-1 ประมาณ 190 ms และ Mumbai ไป US East ประมาณ 220 ms

PDF API แบบ centralized ที่ render 300 ms จะดูแบบนี้จาก Sydney:

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

สำหรับ batch job อาจพอรับได้ แต่สำหรับ preview invoice แบบ interactive จะรู้สึกช้า

ทางเลือกบน edge: Cloudflare ทำงานในหลายร้อยเมือง colo ใกล้ Sydney อาจห่างแค่ไม่กี่ ms:

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

เมื่อ PDF API อยู่บน edge, auth, rate limit และ checkout preview ก็สามารถย้ายเข้ามาใกล้ hot path ได้เช่นกัน

3. Compute ต่อ render สะสมแบบเงียบ ๆ

ตัวอย่าง 100,000 ครั้ง ต่อวัน:

• Puppeteer ประมาณ 600 ms และ 1024 MB: ประมาณ $240/เดือน เฉพาะ compute
• DocRaptor ที่ 89/100,000 หน้า: ประมาณ **2,670/เดือน** สำหรับ 3 ล้าน pages
• gPdf ที่ 5/100,000 หน้า: ประมาณ **150/เดือน** สำหรับ 100,000/day หรือ $5 ถ้าเดือนนั้นมี 100,000 หน้า พอดี

เมื่อถึง 1 ล้าน renders ต่อวัน ช่องว่างยิ่งชัด Puppeteer ประมาณ 2,400/เดือน + ops, DocRaptor ประมาณ 26,700/เดือน, gPdf ประมาณ $1,500/เดือนตาม logic volume เดียวกัน

สาเหตุคือ footprint ของ renderer การเปลี่ยนจาก Chromium process หลายร้อย MB เป็น WASM module ไม่กี่ MB เปลี่ยน unit economics โดยตรง

Edge ให้อะไรจริง ๆ

Latency ที่คาดเดาได้ตอน load สูง

เมื่อไม่มี boot cost ต่อ request ค่า p50 และ p99 จะอยู่ใกล้กัน gPdf มักเห็น p99 อยู่ใน 3x ของ p50 แม้ช่วง spike ส่วน Puppeteer อาจพุ่งถึง 10x ใน cold-start storm

Artifact เดียว deploy ได้ทุกที่

.wasm module ถูก deploy เหมือนกันในทุก Cloudflare colo ไม่ต้องถามว่า pool ที่ Sydney warm แล้วหรือยัง

ทางไปสู่ embedded deployment

ถ้าลูกค้าอยากรัน gPdf ใน VPC, isolated cluster หรือ intranet ของตัวเอง WASM module เดียวกันยังใช้ได้ นี่คือ portable technology ไม่ใช่แค่ hosted SaaS

Edge ไม่เหมาะกับทุกงาน

• Render หลายสิบวินาที: report การเงินขนาดใหญ่อาจเหมาะกับ long-running container
• Render ที่ติด database มาก: OLAP JOIN หนัก ๆ ควรทำใกล้ database แล้วส่ง JSON สุดท้ายไป edge
• Post-processing ที่มี state: signing, archival หรือ watermark pipeline ซับซ้อนอาจต้องอยู่ส่วนกลาง

สำหรับ invoice, label และ receipt B2B ส่วนใหญ่ edge ชนะใน latency, cost และ operations

เมื่อไรควรหยุดทน setup เดิม

ถ้าตรงสามข้อ การ migration น่าทดลองจริง:

• ค่า PDF infrastructure เกิน $300/เดือน
• PDF p99 เกิน 800 ms ใน traffic ปกติ
• เคยมี cold-start incident ที่ลูกค้าเห็น
• ใช้เวลามากกว่า 4 ชั่วโมงกับปัญหา CJK, RTL หรือ emoji glyph
• สร้าง PDF ใน interactive flow
• ให้บริการมากกว่าหนึ่ง geographic region

ถ้าฟังดูคุ้น ๆ Playground สามารถ render invoice ตัวอย่างได้ในไม่กี่ ms