अगर आप रोज कुछ सौ PDF किसी Lambda या छोटे Kubernetes pod से बना रहे हैं, तो architecture बहुत बड़ा मुद्दा नहीं होता। लगभग हर तरीका काम कर जाता है।

लेकिन जैसे ही volume रोज दसियों हजार documents तक पहुंचता है, खासकर e-commerce invoices, shipping labels, payroll slips, BNPL receipts या billing platforms में, तीन चीजें सीधे असर डालती हैं:

Cold-start latency, क्योंकि कहीं न कहीं कोई runtime ठंडा पड़ा होता है।
Regional latency, क्योंकि आपके ग्राहक origin server के पास नहीं होते।
Per-render compute cost, क्योंकि यही खर्च हर दिन हजारों बार दोहरता है।

यहीं edge-deployed renderer, जैसे gPdf, एक अलग category बन जाता है।

1. Cold start concurrency के साथ महंगा होता जाता है

Cold start सिर्फ कभी-कभार की धीमी request नहीं है। यह traffic spike के साथ compound होता है:

Average traffic के लिए 10 warm containers रखे गए।
Black Friday, salary day या quarter-end पर traffic 3x हो गया।
Spike संभालने के लिए 20 नए containers cold-start हुए।
हर container Chromium, Prince या runtime boot करने में 1.5-2.5 seconds लेता है।
अगले 30 seconds तक global p99 खराब रहता है और order pipeline का timeout budget PDF generation में खर्च हो जाता है।

Flat traffic में यह सहनीय है। PDF traffic में नहीं, क्योंकि invoices billing cycle पर, labels pickup windows पर और statements month-end पर spike करते हैं।

Edge विकल्प: Cloudflare Worker isolate 5-20 ms में start होता है, seconds में नहीं। Container नहीं उठता, browser नहीं boot होता, JVM/V8 runtime अलग से initialize नहीं होता। WASM module पहले से चल रहे process में load होता है। gPdf benchmarks में सबसे खराब cold start करीब 12 ms रहा है, वह भी सिर्फ नए isolate की पहली request पर।

2. Regional latency fast render को भी धीमा बना सकती है

Sydney से us-east-1 तक round trip शुरू होने से पहले ही लगभग 200 ms लग जाते हैं। Sao Paulo से eu-west-1 करीब 190 ms, Mumbai से US East करीब 220 ms।

अगर centralized PDF API server-side render में 300 ms लेती है, तो Sydney user को असल अनुभव ऐसा मिलता है:

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

Backend batch job में यह शायद ठीक लगे। लेकिन invoice preview या on-screen download में user को latency साफ दिखती है।

Edge विकल्प: Cloudflare hundreds of cities में चलता है। Sydney के पास का colo लगभग 5 ms दूर हो सकता है:

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

Interactive flows में यह अनुभव बदल देता है। साथ ही auth check, rate limit और checkout preview जैसी adjacent logic भी edge पर लाई जा सकती है, जिससे hot path से round trips कम होते हैं।

3. Per-render compute bill चुपचाप बढ़ता है

1,00,000 रेंडर/day पर साधारण हिसाब:

Puppeteer: ~600 ms, 1024 MB memory के साथ compute ही करीब 240 USD/माह, egress और ops अलग।
DocRaptor: $89/1,00,000 पृष्ठ tier पर 30 लाख पृष्ठ/माह लगभग 2,670 USD/माह।
gPdf: $5/1,00,000 पृष्ठ पर 1,00,000/day लगभग **150 USD/माह**। अगर volume सचमुच 1,00,000/month है तो लगभग$ 5।

10 लाख renders/day पर अंतर और बढ़ता है:

Puppeteer infra: ~2,400 USD/माह + ops + on-call।
DocRaptor: ~26,700 USD/माह।
gPdf: roughly ~1,500 USD/माह on volume pricing.

PDF generation में core cost renderer की footprint से आता है। 600 MB Chromium process को कुछ MB के WASM module से बदलते ही unit economics बदल जाती है।

Edge deployment आपको क्या देता है

Load के नीचे predictable latency

जब हर request पर boot cost नहीं है, तो p50 और p99 पास रहते हैं। gPdf में traffic spike के दौरान भी p99 आम तौर पर p50 के 3x के भीतर रहता है। Puppeteer में cold-start storms p99 को 10x तक ले जा सकते हैं।

हर region में एक जैसा deployable artifact

.wasm module हर Cloudflare colo में एक जैसा deploy होता है। Sydney pool warm है या नहीं, यह सवाल ही नहीं रहता।

Embedded deployment की राह

अगर कोई enterprise customer अपने VPC, isolated cluster या air-gapped network में चलाना चाहे, तो वही WASM module काम आता है। यह सिर्फ hosted SaaS नहीं, portable rendering technology है।

Edge हर जगह सही नहीं है

बहुत लंबे renders। 30-second financial reports या scientific PDFs long-running containers में बेहतर हो सकते हैं।
Database-heavy renders। अगर तीन OLAP tables JOIN करनी हैं, query database के पास करें और final JSON edge को भेजें।
Stateful post-processing। Signing, archival या multi-step watermark pipelines centralized workflow मांग सकते हैं।

लेकिन B2B invoices, labels, receipts और statements की बड़ी majority के लिए edge latency, cost और operations में बेहतर trade-off देता है।

कब current setup बदलना चाहिए

तीन items tick हों तो migration math बदल चुका है:

PDF infrastructure cost 300 USD/माह से ऊपर है।
Normal traffic में PDF p99 800 ms से ज्यादा है।
Cold start incident customers तक पहुंच चुका है।
CJK, RTL या emoji glyphs debug करने में 4 घंटे से ज्यादा लगे हैं।
PDF interactive flow में बनता है।
आप एक से ज्यादा geographic regions में operate करते हैं।

पहले तीन बताते हैं कि आप ज्यादा खर्च करके भी खराब latency झेल रहे हैं। अगले तीन बताते हैं कि centralized renderer product decisions रोक रहा है।

अगर यह परिचित लगता है, Playground आपके browser में 5 ms से कम समय में sample invoice generate कर सकता है।