gPdf
ব্লগ

প্রতিদিন 10K invoice ছাড়ালে edge PDF rendering কেন গুরুত্বপূর্ণ

Cold start, regional latency এবং per-page compute খরচ ভলিউম বাড়লে পুরো হিসাব বদলে দেয়। কখন edge rendering শুধু ভালো ধারণা নয়, বাস্তব সাশ্রয় হয়, সেটাই এখানে।

gPdf Engineering
#edge#scaling#architecture

দিনে কয়েকশ PDF যদি একটি Lambda বা ছোট Kubernetes pod থেকে বানান, architecture খুব বেশি পার্থক্য করে না। প্রায় যে কোনো সমাধান কাজ করবে এবং যথেষ্ট দ্রুত মনে হবে।

কিন্তু দিনে দশ হাজারের বেশি document হলে ছবি বদলে যায়। E-commerce invoice, shipping label, BNPL receipt, payroll slip বা billing platform-এ এই ভলিউম খুব অস্বাভাবিক নয়। তখন তিনটি সংখ্যা কষ্ট দিতে শুরু করে:

  1. Cold-start latency, কারণ কোথাও না কোথাও runtime ঠান্ডা থাকে।
  2. Regional latency, কারণ আপনার customer origin server-এর পাশে থাকে না।
  3. Per-render compute cost, কারণ এই খরচ প্রতিদিন হাজার হাজারবার হয়।

এখানেই gPdf-এর মতো edge-deployed renderer আলাদা category হয়ে ওঠে।

1. Cold start concurrency বাড়লে compound হয়

Cold start শুধু মাঝে মাঝে ধীর request নয়। Traffic spike-এর সঙ্গে এটি বড় হয়:

  • Average traffic ধরে 10টি warm container রাখা হলো।
  • Black Friday, salary day বা month-end-এ traffic 3x হলো।
  • Spike ধরতে 20টি নতুন container cold-start করল।
  • প্রতিটির Chromium, Prince বা runtime boot করতে 1.5-2.5 seconds লাগে।
  • ওই সময় global p99 প্রায় 2 seconds ছুঁতে পারে এবং order pipeline-এর timeout budget PDF generation খেয়ে ফেলে।

Flat traffic হলে সহনীয়। কিন্তু PDF traffic প্রায় সবসময় spike করে: invoice billing boundary-তে, label pickup window-তে, statement month-end-এ।

Edge বিকল্প: Cloudflare Worker isolate 5-20 ms-এ শুরু হয়, seconds নয়। Container নেই, browser boot নেই, আলাদা JVM/V8 startup নেই। WASM module আগে থেকেই চলমান process-এ load হয়। gPdf benchmark-এ সবচেয়ে খারাপ cold start প্রায় 12 ms, সেটিও নতুন isolate-এর প্রথম request।

2. Regional latency সত্যি, render দ্রুত হলেও

Sydney থেকে us-east-1 পৌঁছাতেই প্রায় 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 বা browser download flow-তে user এটি অনুভব করে।

Edge বিকল্প: Cloudflare শত শত শহরে চলে। Sydney customer-এর কাছের colo প্রায় 5 ms দূরে হতে পারে:

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

Interactive flow-তে এটি product experience বদলে দেয়। PDF API edge-এ থাকলে auth, rate limit, checkout preview-এর মতো কাছের logic-ও edge-এ নেওয়া যায়। Hot path থেকে প্রতিটি round trip কমে।

3. Per-render cost নীরবে জমে

১,০০,০০০ রেন্ডার/day-এ সরল হিসাব:

  • Puppeteer: ~600 ms, 1024 MB memory হলে compute-only প্রায় 240 USD/মাস, egress ও ops বাদে।
  • DocRaptor: $89/১,০০,০০০ পৃষ্ঠা tier-এ ৩০ লক্ষ পৃষ্ঠা/মাস প্রায় 2,670 USD/মাস।
  • gPdf: 5/১,০০,০০০ পৃষ্ঠা হলে ১,০০,০০০/day প্রায় **150 USD/মাস**; আর ১,০০,০০০/month হলে প্রায় 5।

১০ লক্ষ renders/day-এ gap আরও বাড়ে:

  • Puppeteer infra: ~2,400 USD/মাস + ops + on-call।
  • DocRaptor: ~26,700 USD/মাস।
  • gPdf: প্রায় ~1,500 USD/মাস volume pricing ধরে।

PDF generation-এর খরচ মূলত renderer footprint থেকে আসে। শত শত MB Chromium process বদলে কয়েক MB WASM module ব্যবহার করলে unit cost structuralভাবে কমে যায়।

Edge deployment আসলে কী দেয়

Load-এর মধ্যেও predictable latency

Per-request boot cost না থাকলে p50 এবং p99 কাছাকাছি থাকে। gPdf-এ spike সময়েও p99 সাধারণত p50-এর 3x-এর মধ্যে থাকে। Puppeteer cold-start storm-এ p99 10x ছুঁতে পারে।

সব জায়গায় একই deployable artifact

.wasm module প্রতিটি Cloudflare colo-তে একইভাবে deploy হয়। Sydney pool warm কিনা, regional concurrency reservation কত, এসব operational প্রশ্ন কমে যায়।

Embedded deployment-এর পথ

Enterprise customer যদি নিজের VPC, isolated cluster বা air-gapped intranet-এ চালাতে চায়, একই WASM module ব্যবহার করা যায়। এটি শুধু hosted SaaS নয়, portable rendering technology।

কোথায় edge ঠিক পছন্দ নয়

  • Multi-second renders। 30-second financial statement বা scientific report long-running container-এ ভালো মানায়।
  • Database-heavy renders। তিনটি OLAP table JOIN করতে হলে database-এর কাছে কাজ করুন, final JSON edge-এ পাঠান।
  • Stateful post-processing। Signing, archival বা complex watermark pipeline centralized flow চাইতে পারে।

কিন্তু B2B invoice, label, receipt ও statement traffic-এর বড় অংশে edge speed, cost এবং operations-এ ভালো trade-off দেয়।

কখন current setup ছাড়ার কথা ভাববেন

তিনটি tick হলে migration math বদলে গেছে:

  • PDF infrastructure cost 300 USD/মাস ছাড়িয়েছে।
  • Normal traffic-এ PDF p99 800 ms-এর বেশি।
  • Cold-start incident customer-কে প্রভাবিত করেছে।
  • CJK, RTL বা emoji glyphs debug করতে 4 ঘণ্টার বেশি গেছে।
  • Interactive flow-তে PDF generate করেন।
  • একাধিক geographic region-এ operate করেন।

প্রথম তিনটি মানে আপনি বেশি খরচ করেও latency risk নিচ্ছেন। পরের তিনটি মানে centralized renderer আপনার product decision সীমিত করছে।

পরিচিত লাগলে Playground browser-এই 5 ms-এর কম সময়ে sample invoice generate করে দেখাবে।