কোথায় চালাবেন — VPS, shared hosting, PaaS আর serverless

১ · চার জায়গা, একটি দোকান

বাজারঘর এখন প্রায় তৈরি। Next.js 16-এর দোকানের পাতা, Express বা route handler-এর API (পর্ব ৫৭), Prisma আর PostgreSQL, Redis-এর cache (পর্ব ৪৪), background worker আর cron (পর্ব ৬২), আর অর্ডারের live আপডেটের জন্য WebSocket (পর্ব ৬০)। এবার প্রশ্ন: এসব চলবে কোথায়?

তত্ত্বের দিক, অর্থাৎ IaaS, PaaS আর FaaS কী, public আর private cloud কী, Cloud & DevOps কোর্সের deployment model আর কোন compute কখন পর্বে আছে। এখানে আমরা একজন ফুল-স্ট্যাক ডেভেলপারের চোখে দেখব: আমার অ্যাপের কোন টুকরো কোথায় বসবে, আর কোথায় বসালে কী ভাঙবে।

• Shared hosting: একটি server-এ অনেক গ্রাহক, প্রত্যেকে একটি ফোল্ডার আর একটি cPanel পান। সাধারণত Apache বা LiteSpeed, PHP আর MySQL থাকে।
• VPS: একটি virtual যন্ত্র, পূর্ণ root অধিকারসহ। OS থেকে firewall পর্যন্ত সব আপনার।
• PaaS: আপনি কোড বা container দেন, platform build করে, চালায়, পড়ে গেলে তোলে। ডেটাবেস প্রায়ই পাশের একটি managed সেবা।
• Serverless: কোড ছোট function হিসেবে অনুরোধ এলে চলে, ভিড়ে অনেক কপি হয়, অলস হলে শূন্যে নামে।

কোন অংশ কোথায় চলে

নিচের টেবিলটি এই পর্বের মেরুদণ্ড। “হ্যাঁ” মানে সাধারণভাবে স্বাভাবিক পথে চলে; “শর্তে” মানে কোনো বিশেষ সুবিধা বা কৌশল লাগে, আর সেটি সেবাদাতা ভেদে আলাদা। নির্দিষ্ট কোনো সেবার জন্য তাদের বর্তমান নথি দেখে মিলিয়ে নিন।

টেবিল থেকেই একটি নিয়ম বেরিয়ে আসে: যে কাজ দীর্ঘক্ষণ বেঁচে থাকা process চায় (WebSocket-এর খোলা সংযোগ, পাঁচ মিনিটের PDF job, queue-র worker), সেটি VPS বা PaaS-এ স্বাভাবিক, serverless-এ কষ্টের, shared hosting-এ প্রায় অসম্ভব। আর যে কাজ শুধু ফাইল দেয়, সেটি যেকোনো জায়গায় চলে, সবচেয়ে ভালো চলে CDN থেকে।

২ · Shared hosting আর cPanel — বাংলাদেশের পরিচিত পথ

বাংলাদেশে বহু ছোট ব্যবসা, স্কুল আর ফ্রিল্যান্সার স্থানীয় বা বিদেশি hosting কোম্পানির cPanel-ওয়ালা প্যাকেজ ব্যবহার করেন। কারণগুলো বাস্তব: টাকায় বিল দেওয়া যায়, বাংলায় support মেলে, আর বছরে একবার নবায়ন করলেই চলে। কোন প্যাকেজে ঠিক কী আছে, তা প্রতিষ্ঠান আর প্যাকেজ ভেদে অনেক আলাদা। তাই এখানে যা বলছি, তা সাধারণ চিত্র; কেনার আগে নিজের hosting-এর বিবরণ মিলিয়ে নিন।

যা সাধারণত পাবেন, আর যা পাবেন না

• পাবেন: public_html ফোল্ডার, File Manager, FTP, MySQL বা MariaDB, PHP, email, cron job, আর প্রায়ই বিনা খরচের TLS certificate.
• পাবেন না: root অধিকার, নিজের মতো package install, যেকোনো port-এ শোনা, আর চিরকাল চলা process. প্রতিটি অ্যাকাউন্টের CPU, মেমরি আর process-এর সংখ্যায় সীমা থাকে; অনেক hosting-এ এই সীমা CloudLinux-এর মতো ব্যবস্থায় বাঁধা।
• কখনো কখনো পাবেন: Node.js বা Python অ্যাপ চালানোর একটি অংশ। cPanel-এর নিজস্ব Application Manager, বা CloudLinux-এর “Setup Node.js App” জাতীয় সুবিধা, যেখানে hosting এটি চালু রেখেছে। সাধারণত এগুলো Phusion Passenger-এর মতো একটি app server দিয়ে আপনার অ্যাপ চালায়, আর অলস থাকলে process থামিয়ে দিতে পারে। আপনার প্যাকেজে এটি আছে কি না, আর থাকলে কোন Node version, তা hosting-কেই জিজ্ঞেস করুন।

বাজারঘরের তিনটি পথ shared hosting-এ

নিচের stepper-এ static export কীভাবে cPanel-এ ওঠে, ধাপে ধাপে দেখুন। ফাইলের সংখ্যা আর আকার পর্ব ৫৫-এর সত্যিকারের build থেকে; cPanel-এর ধাপগুলো সাধারণ বিবরণ, কারণ আমরা কোনো আসল hosting-এ তুলিনি।

next.config.mjs: output: 'export', trailingSlash: true
$ npx next build
out/index.html
out/products/1/index.html
out/_next/static/…
৪৪টি ফাইল, 766 KB

cd out
zip -r ../site.zip .
# out/ ফোল্ডারটি নয়, তার ভেতরের জিনিস

public_html/
  index.html
  404.html
  products/1/index.html
  _next/static/…
  .htaccess   ← আগে থেকে থাকলে মুছবেন না

ErrorDocument 404 /404.html
<IfModule mod_headers.c>
  <FilesMatch "\.html$">
    Header set Cache-Control "no-cache"
  </FilesMatch>
</IfModule>

$ curl -I https://bazarghar.example/products/1/
HTTP/2 200
content-type: text/html
cache-control: no-cache
নমুনা আউটপুট: আসল hosting-এ চালানো নয়

৩ · VPS ঠিকভাবে — standalone build আর pm2

VPS-এ স্বাধীনতা পুরো, দায়িত্বও পুরো। আমরা কোনো আসল VPS ভাড়া করিনি; একই কাজ নিজের যন্ত্রে 127.0.0.1-এ মহড়া দিয়েছি। নিচের প্রতিটি আউটপুট সেই সত্যিকারের run থেকে, লেখার সময়ের version-এ: Next.js 16.4.4, React 19.3.1, pm2 7.1.1, Caddy 2.11.7, Node 24. যন্ত্রটি Windows ছিল, যা পার্থক্য তৈরি করেছে এক জায়গায়, সেটি নিচে বলা আছে। Linux server-এর ভিত্তি, যেমন user, permission আর package, Cloud & DevOps-এর Server-এর Linux পর্বে।

ধাপ ১: standalone build

সাধারণ next start চালাতে server-এ পুরো node_modules লাগে। output: 'standalone' দিলে Next.js build-এর সময় খুঁজে বের করে কোন ফাইল সত্যিই লাগবে, আর শুধু সেগুলো নিয়ে .next/standalone ফোল্ডার আর একটি ছোট server.js বানায়। এটাই standalone output.

/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'standalone',
};
export default nextConfig;

~/bazarghar$ npx next build
▲ Next.js 16.4.4 (Turbopack)
…
Route (app)
┌ ○ /
├ ○ /_not-found
├ ƒ /api/health
├ ƒ /api/lab-crash
└ ƒ /products

○  (Static)   prerendered as static content
ƒ  (Dynamic)  server-rendered on demand

~/bazarghar$ cp -r public .next/standalone/ && cp -r .next/static .next/standalone/.next/
~/bazarghar$ du -sh .next/standalone node_modules
32M	.next/standalone
351M	node_modules

ধাপ ২: pm2 দিয়ে চালু রাখা

node server.js হাতে চালালে terminal বন্ধ হলেই দোকান বন্ধ, crash হলে কেউ আবার চালাবে না। দরকার একটি process supervisor. Linux-এ systemd নিজেই এ কাজ পারে (systemd-এর পর্ব); Node-এর জগতে জনপ্রিয় বিকল্প pm2, যা একসাথে cluster, log আর reload দেয়। আমাদের ecosystem ফাইল:

module.exports = {
  apps: [{
    name: 'bazarghar-web',
    script: '.next/standalone/server.js',
    exec_mode: 'cluster',
    instances: 2,               // CPU core অনুযায়ী; 'max' দিলে সব core
    env: { NODE_ENV: 'production', PORT: 47382, HOSTNAME: '127.0.0.1' },
    out_file: 'logs/web-out.log',
    error_file: 'logs/web-error.log',
    time: true,                 // log-এর প্রতিটি লাইনে সময়
    max_memory_restart: '300M', // মেমরি ফাঁস হলে আবার চালু
    kill_timeout: 10000,        // বন্ধের আগে চলমান অনুরোধ শেষ করার সময়
  }],
};

HOSTNAME: '127.0.0.1' খেয়াল করুন: Node শুধু যন্ত্রের ভেতর থেকে পৌঁছানো যায় এমন ঠিকানায় শোনে, বাইরের দুনিয়া কথা বলবে শুধু proxy-র সাথে। এবার চালানো, আর সমানভাবে ভাগ হচ্ছে কি না দেখা:

~/bazarghar$ pm2 start ecosystem.config.js
[PM2][WARN] Applications bazarghar-web not running, starting...
[PM2] App [bazarghar-web] launched (2 instances)

~/bazarghar$ node count-pids.js      # ছোট script: ২০টি অনুরোধ, প্রতিটির pid গোনা
{ '29580': 20 }                      # Windows, ডিফল্ট নিয়ম

~/bazarghar$ pm2 kill && NODE_CLUSTER_SCHED_POLICY=rr pm2 start ecosystem.config.js
~/bazarghar$ node count-pids.js
{ '12432': 10, '23920': 10 }         # round-robin

ধাপ ৩: crash, আবার চালু, আর log

এবার ইচ্ছে করে একটি worker মেরে ফেলি। ল্যাবের route process-কে process.exit(1) করে:

~/bazarghar$ curl -s -X POST http://127.0.0.1:47382/api/lab-crash
{"bye":23920}
~/bazarghar$ pm2 ls
┌────┬──────────────────┬─────────────┬─────────┬─────────┬──────────┬────────┬──────┬───────────┬──────────┬──────────┬──────────┬──────────┐
│ id │ name             │ namespace   │ version │ mode    │ pid      │ uptime │ ↺    │ status    │ cpu      │ mem      │ user     │ watching │
├────┼──────────────────┼─────────────┼─────────┼─────────┼──────────┼────────┼──────┼───────────┼──────────┼──────────┼──────────┼──────────┤
│ 0  │ bazarghar-web    │ default     │ 1.0.0   │ cluster │ 6592     │ 3s     │ 1    │ online    │ 0%       │ 90.3mb   │ deploy   │ disabled │
│ 1  │ bazarghar-web    │ default     │ 1.0.0   │ cluster │ 12432    │ 13s    │ 0    │ online    │ 0%       │ 95.0mb   │ deploy   │ disabled │
└────┴──────────────────┴─────────────┴─────────┴─────────┴──────────┴────────┴──────┴───────────┴──────────┴──────────┴──────────┴──────────┘
~/bazarghar$ for i in 1 2 3 4; do curl -s http://127.0.0.1:47382/api/health; echo; done
{"ok":true,"pid":12432}
{"ok":true,"pid":6592}
{"ok":true,"pid":12432}
{"ok":true,"pid":6592}
~/bazarghar$ tail -n 1 logs/web-error-0.log
2026-11-03T17:16:27: lab: worker exiting on purpose

pm2 নিজে কী করছে, তার একটি খেলনা মডেল নিচে। দুটি worker, পালা করে অনুরোধ, একটি অনুরোধ চলার মাঝেই worker 1 মারা যায়, আর supervisor দুই tick পরে নতুন pid নিয়ে তাকে ফেরায়। চালিয়ে দেখুন, তারপর t === 4 বদলে অন্য সময়ে crash ঘটান।

// pm2 cluster-এর খেলনা মডেল: round-robin, একটি worker crash, supervisor আবার চালায়
const workers = [{ id: 0, pid: 101, up: true, restarts: 0 },
                 { id: 1, pid: 102, up: true, restarts: 0 }];
let nextPid = 103, rr = 0, ok = 0, failed = 0, restartAt = null;
const RESTART_DELAY = 2;              // ধরে নেওয়া: নতুন process তৈরি হতে ২ tick

function pick() {                     // পরের জীবিত worker, পালা করে
  for (let i = 0; i < workers.length; i++) {
    const w = workers[(rr + i) % workers.length];
    if (w.up) { rr = (rr + i + 1) % workers.length; return w; }
  }
  return null;
}

for (let t = 1; t <= 9; t++) {
  if (t === restartAt) {
    const w = workers[1];
    Object.assign(w, { up: true, pid: nextPid++, restarts: w.restarts + 1 });
    console.log(`t=${t} supervisor: worker 1 back as pid ${w.pid} (restarts ${w.restarts})`);
  }
  const w = pick();
  if (t === 4) {                      // এই অনুরোধ চলার সময়েই process মারা গেল
    w.up = false; failed++; restartAt = t + RESTART_DELAY;
    console.log(`t=${t} GET -> worker ${w.id} pid ${w.pid}  CRASH, proxy answers 502`);
    continue;
  }
  ok++;
  console.log(`t=${t} GET -> worker ${w.id} pid ${w.pid}  200`);
}
console.log(`ok ${ok}, failed ${failed}`);

৪ · সামনে reverse proxy — Caddy, compression আর cache header

Next.js-এর self-hosting নথি সরাসরি বলে: Next.js server-কে সরাসরি ইন্টারনেটে না রেখে সামনে একটি reverse proxy রাখুন, যা ভাঙা অনুরোধ, ধীরে ধীরে পাঠানো সংযোগের আক্রমণ, payload-এর সীমা আর rate limit সামলাবে। হোটেলের রিসেপশনের মতো: অতিথি সরাসরি রান্নাঘরে ঢোকেন না, রিসেপশন যাচাই করে ঠিক জায়গায় পাঠায়। Nginx-এর virtual host, TLS আর proxy-র বিস্তারিত Cloud & DevOps-এর Nginx আর reverse proxy পর্বে; এখানে আমরা Caddy ব্যবহার করেছি, কারণ এর config ছোট আর আসল domain-এ এটি নিজেই certificate নেয়। Caddy-র Windows binary তাদের release-এর checksum ফাইলের সাথে মিলিয়ে তবেই চালানো হয়েছে।

{
	admin 127.0.0.1:47389
	auto_https off
}

http://127.0.0.1:47380 {
	bind 127.0.0.1
	encode zstd gzip

	# hash-ওয়ালা JS/CSS: disk থেকে সরাসরি, এক বছরের cache
	handle_path /_next/static/* {
		root * .next/static
		header Cache-Control "public, max-age=31536000, immutable"
		file_server
	}

	# বাকি সব: Node (pm2 cluster)
	handle {
		reverse_proxy 127.0.0.1:47382
	}

	header -Server
	log {
		output file logs/caddy-access.log
		format json
	}
}

ল্যাবে auto_https off আর http://, কারণ 127.0.0.1-এর জন্য কোনো public certificate হয় না। প্রথমবার bind ছাড়া চালিয়ে দেখা গেল Caddy 0.0.0.0:47380-এ শুনছে, অর্থাৎ সব network-এ; site-এর ঠিকানায় 127.0.0.1 লেখা থাকলেও। bind 127.0.0.1 যোগ করে তবেই শুধু ভেতরে সীমিত হলো। আসল server-এ এ ধরনের ভুল ধরতে ss -tlnp বা netstat দিয়ে কে কোথায় শুনছে তা দেখার অভ্যাস রাখুন। এবার তিনটি অনুরোধ:

~/bazarghar$ curl -sS -D - -o /dev/null -H 'Accept-Encoding: gzip, zstd' http://127.0.0.1:47380/
HTTP/1.1 200 OK
Cache-Control: s-maxage=31536000
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Etag: "pr41o7sdnu3l2"
Vary: rsc, next-router-state-tree, next-router-prefetch, next-router-segment-prefetch, Accept-Encoding
Via: 1.1 Caddy
X-Nextjs-Cache: HIT
X-Nextjs-Prerender: 1
X-Powered-By: Next.js
…
~/bazarghar$ curl -sS -D - -o /dev/null -H 'Accept-Encoding: gzip' http://127.0.0.1:47380/products
HTTP/1.1 200 OK
Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate
Content-Encoding: gzip
Via: 1.1 Caddy
…
~/bazarghar$ curl -sS -D - -o /dev/null -H 'Accept-Encoding: gzip' http://127.0.0.1:47380/_next/static/chunks/0cz1d0mv5g_q7.js
HTTP/1.1 200 OK
Cache-Control: public, max-age=31536000, immutable
Content-Encoding: gzip
Content-Type: text/javascript; charset=utf-8
…
~/bazarghar$ for e in identity gzip zstd; do curl -s -o /dev/null -H "Accept-Encoding: $e" \
    -w "$e: %{size_download} bytes\n" http://127.0.0.1:47380/_next/static/chunks/0cz1d0mv5g_q7.js; done
identity: 112594 bytes
gzip: 41106 bytes
zstd: 41881 bytes

একটি অনুরোধের পুরো পথ

আসল production-এ সামনে আরও দুটি স্তর যোগ হয়: DNS আর CDN. নিচের stepper-এ একটি ক্রেতার দুটি অনুরোধ দেখুন: একটি JS ফাইল আর একটি /products পাতা। Header-এর মান ওপরের সত্যিকারের run থেকে; DNS আর CDN-এর অংশ বর্ণনা, কারণ কোনো আসল domain বা CDN ব্যবহার করা হয়নি। IP ঠিকানাগুলো নথিতে উদাহরণের জন্য সংরক্ষিত পরিসর থেকে।

আসল domain-এ TLS, firewall আর SSH

এই অংশ আমরা চালাইনি, কারণ এর জন্য আসল domain আর public server লাগে। সাধারণ পথটি এমন:

• TLS: domain-এর A record VPS-এর IP-তে দিন। Caddy-তে site-এর ঠিকানা হিসেবে শুধু bazarghar.example লিখলে Caddy নিজেই Let's Encrypt বা অন্য ACME সেবা থেকে certificate নেয় আর নবায়ন করে। Nginx-এ এ কাজ সাধারণত certbot করে। Let's Encrypt-এর certificate স্বল্পমেয়াদি (লেখার সময়ে ৯০ দিন, আর মেয়াদ আরও কমানোর পরিকল্পনা তাঁরা ঘোষণা করেছেন), তাই নবায়ন স্বয়ংক্রিয় না হলে একদিন দোকান হঠাৎ “Not secure” দেখাবে। ACME-র HTTP challenge-এর জন্য port 80 খোলা থাকা লাগে। TLS-এর ভেতরের কাজ Computer Networks-এর TLS আর HTTPS পর্বে।
• Firewall: বাইরে থেকে শুধু 22, 80, 443. PostgreSQL-এর 5432 বা Redis-এর 6379 কখনো ইন্টারনেটে খোলা নয়। cloud-এর security group আর OS-এর firewall দুই স্তরেই নিয়ম রাখা ভালো; তত্ত্ব security group পর্বে।
• SSH: password দিয়ে login বন্ধ, শুধু key; root দিয়ে সরাসরি login বন্ধ, আলাদা একটি user; বারবার ভুল login ঠেকাতে fail2ban-এর মতো টুল। বিস্তারিত SSH আর দূরের server পর্বে।
• Reboot-এর পর: pm2 startup OS-এর জন্য একটি startup script তৈরির কমান্ড দেখায়, আর pm2 save বর্তমান process-এর তালিকা মনে রাখে। দুটি না করলে server restart-এর পর দোকান বন্ধ থাকবে। এগুলো আমরা Windows-এ চালাইনি।

৫ · Zero-downtime reload — মেপে দেখা

নতুন কোড এলে পুরোনো process থামিয়ে নতুনটি চালাতে হয়। মাঝের কয়েক সেকেন্ডে যাঁরা অর্ডার দিচ্ছেন, তাঁদের কী হয়? Zero-downtime reload-এর দাবি: কিছুই হবে না। দাবিটি আমরা মেপে দেখেছি। একটি ছোট script চারটি সমান্তরাল loop-এ ১২ সেকেন্ড ধরে Caddy-র মাধ্যমে /api/health-এ অনুরোধ পাঠায়, প্রতিটি নতুন সংযোগে, আর ফল গোনে। তিন সেকেন্ড পর চালানো হয় reload.

~/bazarghar$ node load.js http://127.0.0.1:47380/api/health 12 &  sleep 3;  pm2 reload bazarghar-web
[PM2] Applying action reloadProcessId on app [bazarghar-web](ids: [ 0, 1 ])
[PM2] [bazarghar-web](0) ✓
[PM2] [bazarghar-web](1) ✓
requests: 23745
ok: 23745  failed: 0
status codes: {"200":23745}
network errors: {}
worker pids seen: 12432, 6592, 33336, 33360

~/bazarghar$ node load.js http://127.0.0.1:47380/api/health 12 &  sleep 3;  pm2 restart bazarghar-web
[PM2] Applying action restartProcessId on app [bazarghar-web](ids: [ 0, 1 ])
[PM2] [bazarghar-web](0) ✓
[PM2] [bazarghar-web](1) ✓
requests: 16384
ok: 16001  failed: 383
status codes: {"200":16001,"502":383}
network errors: {}
worker pids seen: 33336, 33360, 29784

Reload-এর সময় ভেতরে কী ঘটে, নিচের stepper-এ দেখুন। ক্রমটি pm2-এর নথির বর্ণনা অনুযায়ী (cluster mode-এ একটি একটি করে বদলানো); pid আর শেষ সংখ্যা ওপরের run থেকে।

৬ · ডেটাবেস — managed না নিজের, আর backup

অ্যাপ server ভাঙলে আবার চালানো যায়; ডেটাবেস ভাঙলে ক্রেতার অর্ডার আর টাকার হিসাব চলে যায়। তাই কোথায় চালাবেন প্রশ্নে ডেটাবেসের সিদ্ধান্তই সবচেয়ে ভারী।

বিস্তারিত (replica, failover, connection) Cloud & DevOps-এর Managed database পর্বে। ছোট দোকানের জন্য একটি বাস্তব মাঝামাঝি পথ: অ্যাপ VPS-এ, ডেটাবেস managed. তাতে খরচ বাড়ে, কিন্তু সবচেয়ে ঝুঁকির কাজটি, backup আর restore, অভিজ্ঞ কারও হাতে যায়।

নিজে চালালে backup-এর ন্যূনতম নিয়ম

• প্রতিদিন dump, অন্য জায়গায়: pg_dump দিয়ে dump নিয়ে VPS-এর বাইরে, যেমন object storage-এ (পর্ব ৬৪)। একই disk-এ রাখা backup disk নষ্ট হলে সাথেই যায়।
• কতটা হারানো চলবে, আগে ঠিক করুন: দিনে একবার dump মানে খারাপ দিনে প্রায় ২৪ ঘণ্টার অর্ডার হারাতে পারেন। এর চেয়ে কম চাইলে WAL archiving আর PITR লাগে, যা managed সেবায় সহজ। RPO আর RTO-র তত্ত্ব Backup আর disaster recovery পর্বে।
• Restore মহড়া: মাসে অন্তত একবার নতুন একটি খালি ডেটাবেসে backup ফিরিয়ে দেখুন, আর গুনে দেখুন অর্ডারের সংখ্যা মেলে কি না। পরীক্ষা না করা backup আসলে একটি আশা মাত্র।

সংযোগের হিসাব

VPS-এ হিসাব সহজ: ২টি pm2 worker, প্রতিটিতে pool-এর আকার ১০ হলে সর্বোচ্চ ২০টি সংযোগ, সাথে worker process-এর কয়েকটি। PostgreSQL-এর ডিফল্ট max_connections ১০০, তাই অনেক জায়গা বাকি। Serverless-এ ছবিটি উল্টো: ভিড়ে platform ৫০টি কপি চালালে, প্রতিটিতে pool ৫ হলে, ২৫০টি সংযোগের চাওয়া, যা ১০০-র সীমা আড়াই গুণ ছাড়ায়। পর্ব ৩৮-এ এই সমস্যা সত্যিকারের PostgreSQL-এ ঘটিয়ে দেখানো হয়েছে, আর সমাধান: প্রতিটি কপিতে ছোট pool, আর মাঝে একটি connection pooler.

৭ · PaaS আর serverless — সুবিধা, সীমা আর cold start

PaaS: শোরুম ভাড়া

PaaS-এ আপনি repository যুক্ত করেন বা container image দেন; platform build করে, process চালায়, health check দেখে, crash হলে তোলে, TLS দেয়, আর অনেক সময় নতুন version চালু করার আগে পুরোনোটিকে রেখে দেয়। Render, Railway, Fly.io, Heroku বা DigitalOcean App Platform এমন সেবার উদাহরণ; প্রত্যেকের নিয়ম, region আর দাম আলাদা আর সময়ের সাথে বদলায়, তাই তাদের বর্তমান নথিই চূড়ান্ত। বাজারঘরের জন্য সাধারণ রূপ হলো তিনটি আলাদা জিনিস: একটি web সেবা (Next.js), একটি worker সেবা (queue-র job আর cron), আর পাশে managed PostgreSQL ও Redis. দীর্ঘজীবী process হওয়ায় WebSocket আর লম্বা job এখানে স্বাভাবিকভাবে চলে, যদি না platform নির্দিষ্ট কোনো সময়সীমা বা idle-এ ঘুম পাড়ানোর নিয়ম রাখে (কিছু সস্তা বা বিনা খরচের প্ল্যানে এমন নিয়ম থাকে)।

Serverless: মেলার স্টল

Serverless platform-এ, যেমন Vercel, Netlify, Cloudflare Workers বা AWS Lambda-ভিত্তিক সেবায়, Next.js-এর প্রতিটি dynamic route এক বা একাধিক function হয়ে যায়, আর static অংশ যায় CDN-এ। Trigger, concurrency আর সীমার তত্ত্ব Cloud & DevOps-এর Serverless function পর্বে। ফুল-স্ট্যাক ডেভেলপারের কাছে তিনটি জিনিস ভাঙে:

• WebSocket: function একটি অনুরোধ নিয়ে একটি উত্তর দিয়ে শেষ হয়; ঘণ্টার পর ঘণ্টা খোলা সংযোগ রাখার জায়গা নেই। পর্ব ৬০-এ দেখেছেন, তখন আলাদা একটি দীর্ঘজীবী realtime সার্ভিস বা managed realtime সেবা লাগে; অনেক ক্ষেত্রে SSE (পর্ব ৬১) সহজ বিকল্প।
• লম্বা job: প্রতিটি function-এর চলার সময়ের একটি সর্বোচ্চ সীমা থাকে, যা platform আর প্ল্যান ভেদে সেকেন্ড থেকে মিনিটের ঘরে। আট মিনিটের PDF রিপোর্ট সেখানে মাঝপথে কেটে যেতে পারে। সমাধান: কাজটি queue-তে দিন আর আলাদা worker-এ চালান (পর্ব ৬২), অথবা কাজটি ছোট টুকরোয় ভাঙুন।
• PostgreSQL-এর সংযোগ: ওপরের হিসাব। Pooler ছাড়া serverless আর সাধারণ PostgreSQL একসাথে ভিড়ের দিনে ভাঙে।

Cold start: প্রথম ক্রেতার অপেক্ষা

অনেকক্ষণ অনুরোধ না এলে platform instance বন্ধ করে দেয়, যাতে খরচ শূন্যে নামে। পরের অনুরোধে নতুন instance চালু, runtime আর কোড load, তারপর কাজ: এই বাড়তি সময়ের নাম cold start. কতটা বাড়তি, তা platform, runtime, bundle-এর আকার আর ডেটাবেসে প্রথম সংযোগের ওপর নির্ভর করে; কিছু platform আগে থেকে গরম রাখা বা প্রস্তুত instance-এর সুবিধা দেয়। আমরা কোনো আসল platform মাপিনি, তাই নিচের মডেলের সংখ্যাগুলো ধরে নেওয়া। ধারণাটি দেখার জন্য: কম ভিড়ের API-তে cold start কত ঘন ঘন পড়ে।

// নকল ঘড়ি; সব সংখ্যা ধরে নেওয়া, মাপা নয়
const COLD_MS = 900;            // নতুন instance চালু + code load
const WARM_MS = 60;             // গরম instance-এ স্বাভাবিক কাজ
const IDLE_LIMIT_MIN = 10;      // এত মিনিট অলস থাকলে platform instance বন্ধ করে
// এক দুপুরে বাজারঘরের admin API-তে অনুরোধ আসার সময় (মিনিট)
const arrivals = [0, 1, 2, 3, 20, 21, 45, 46, 47, 48, 49, 90];

let lastSeen = -Infinity;
const lat = [];
for (const m of arrivals) {
  const cold = m - lastSeen > IDLE_LIMIT_MIN;
  const ms = cold ? COLD_MS + WARM_MS : WARM_MS;
  lat.push(ms);
  console.log(`t=${String(m).padStart(2)} min  ${cold ? 'COLD' : 'warm'}  ${ms} ms`);
  lastSeen = m;
}
const sorted = [...lat].sort((a, b) => a - b);
const pct = (q) => sorted[Math.ceil(q * sorted.length) - 1];
const mean = lat.reduce((a, b) => a + b, 0) / lat.length;
const colds = lat.filter((x) => x > WARM_MS).length;
console.log(`cold: ${colds}/${lat.length}  mean: ${mean.toFixed(0)} ms  p50: ${pct(0.5)} ms  p95: ${pct(0.95)} ms`);
console.log(`always-on server (VPS/PaaS): every request ${WARM_MS} ms`);

Lock-in আর OpenNext

Next.js আর Vercel একই প্রতিষ্ঠানের, তাই প্রশ্ন ওঠে: অন্য কোথাও কি সব সুবিধা পুরোপুরি চলে? Next.js-এর deploy নথি অনুযায়ী Node.js server বা Docker-এ চালালে সব feature সমর্থিত, static export-এ সীমিত, আর অন্য platform-এ চলে adapter দিয়ে। Next.js একটি public Deployment Adapter API দিয়েছে, যাতে platform-গুলোকে build-এর ভেতরের গঠন অনুমান করে চলতে না হয়। OpenNext হলো একটি open-source উদ্যোগ, যার নিজের বর্ণনা অনুযায়ী এর AWS, Cloudflare আর Netlify-র adapter আছে, ভিন্ন ভিন্ন দলের রক্ষণাবেক্ষণে। কোন feature কোন platform-এ কতটা চলে, তা সময়ের সাথে বদলাচ্ছে; তাই নির্দিষ্ট platform বাছার আগে সেখানে নিজের অ্যাপের ISR, Server Action, image আর proxy চালিয়ে দেখুন। Lock-in-এর আসল খরচ সাধারণত কোডে নয়, platform-এর নিজস্ব সেবায়: তাদের KV store, queue, cron বা image সেবায় যত বেশি নির্ভর করবেন, সরে যাওয়া তত কঠিন।

৮ · খরচ, domain আর বাংলাদেশ থেকে দূরত্ব

মাসিক খরচ: ধরে নেওয়া সংখ্যায়

এই কোর্স কোনো দাম ঘটনা হিসেবে বলে না, কারণ দাম বদলায়, মুদ্রার হার বদলায়, আর সেবাদাতারা প্রায়ই প্ল্যান সাজান নতুনভাবে। নিচের ক্যালকুলেটরের প্রতিটি সংখ্যা ধরে নেওয়া, কোনো vendor-এর আসল দাম নয়: 1 USD = 122 টাকা, বছরে ৬,০০০ টাকার cPanel প্ল্যান, মাসে 12 ডলারের 2 vCPU/4 GB VPS, ইত্যাদি। কাজ হলো তুলনার কাঠামো শেখা; নিজের পাওয়া দাম বসিয়ে আবার চালান। Cloud বিলের তত্ত্ব, যেমন on-demand, reserved আর data transfer, Cloud-এর বিল পর্বে।

// সব দাম ধরে নেওয়া উদাহরণ (assumption), কোনো vendor-এর আসল দাম নয়
const RATE = 122;                         // ধরে নেওয়া: 1 USD = 122 টাকা
const domain = ['domain .com', 1800 / 12, 'BDT'];   // বছরে 1800 টাকা
const plans = {
  'Shared hosting':   [['cPanel plan', 6000 / 12, 'BDT'], domain],
  'VPS, all on it':   [['VPS 2 vCPU 4 GB', 12, 'USD'], ['VPS backup', 2.4, 'USD'],
                       ['offsite DB dumps', 1, 'USD'], domain],
  'VPS + managed DB': [['VPS 2 vCPU 4 GB', 12, 'USD'], ['managed Postgres', 15, 'USD'],
                       domain],
  'PaaS':             [['web service', 7, 'USD'], ['worker service', 7, 'USD'],
                       ['managed Postgres', 15, 'USD'], ['managed Redis', 10, 'USD'], domain],
  'Serverless':       [['platform plan', 20, 'USD'], ['serverless Postgres', 19, 'USD'],
                       ['Redis per request', 5, 'USD'], domain],
};
const usdOf = ([, amount, cur]) => (cur === 'USD' ? amount : amount / RATE);

console.log('plan'.padEnd(18), 'USD/mo'.padStart(8), 'BDT/mo'.padStart(8), 'BDT/yr'.padStart(9));
for (const [name, items] of Object.entries(plans)) {
  const usd = items.reduce((sum, it) => sum + usdOf(it), 0);
  console.log(name.padEnd(18), usd.toFixed(2).padStart(8),
    String(Math.round(usd * RATE)).padStart(8), String(Math.round(usd * RATE * 12)).padStart(9));
}

Domain, DNS আর CDN

যেখানেই চালান, domain-এর DNS-এ কয়েকটি record লাগে: A (বা IPv6-এর AAAA) record server বা CDN-এর ঠিকানায়, www-এর জন্য CNAME, আর email-এর জন্য MX, SPF ও DKIM (পর্ব ৬৩)। PaaS বা serverless সাধারণত একটি CNAME বা নির্দিষ্ট A record দিতে বলে, আর certificate নিজেরাই নেয়। Server বদলানোর আগের দিন TTL কমিয়ে রাখলে নতুন ঠিকানা দ্রুত ছড়ায়। CDN সামনে রাখলে static ফাইল কাছের edge থেকে যায় আর VPS-এর IP লুকানো থাকে; বিস্তারিত CDN, WAF আর edge পর্বে।

বাংলাদেশ থেকে কোন region

অনেক সেবাদাতার বাংলাদেশের ভেতরে region নেই; কাছের সাধারণ পছন্দ Singapore আর Mumbai. আমরা কোনো latency মাপিনি, তাই নিচের সংখ্যা শুধু পদার্থবিদ্যার নিচের সীমা। Fiber-এ আলো মোটামুটি সেকেন্ডে ২ লাখ কিলোমিটার চলে, অর্থাৎ প্রতি মিলিসেকেন্ডে প্রায় ২০০ কিলোমিটার। Round trip-এ দূরত্ব দুবার।

দূরত্ব শহরের স্থানাঙ্ক থেকে great-circle সূত্রে হিসাব করা। ৩ RTT-এর যুক্তি: TCP handshake ১, TLS 1.3 handshake ১, আর অনুরোধ-উত্তর ১. বাস্তবে cable সোজা পথে যায় না, মাঝে routing আর server-এর নিজের সময় যোগ হয়, তাই আসল সংখ্যা এর চেয়ে বেশিই হবে; কতটা বেশি, তা নিজের ISP থেকে ping বা curl -w দিয়ে মাপুন। সিদ্ধান্তের নিয়মটি অবশ্য পরিষ্কার: অ্যাপ server আর ডেটাবেস একই region-এ রাখুন, কারণ একটি পাতায় পাঁচটি query হলে সেই দূরত্ব পাঁচবার গোনা হয়।

৯ · সিদ্ধান্তের ছক

সব মিলিয়ে চারটি প্রশ্ন বেশিরভাগ সিদ্ধান্ত ঠিক করে দেয়: Node server আদৌ লাগে কি না; দীর্ঘজীবী process (WebSocket, লম্বা job) লাগে কি না; Linux চালানোর মতো কেউ আছেন কি না; আর ট্রাফিক কি স্থির, নাকি হঠাৎ লাফায়। নিচের function এই প্রশ্নগুলো একটি সরল নিয়মে বাঁধে। এটি একটি শেখার মডেল, কোনো সর্বজনীন উত্তর নয়: platform-এর সর্বোচ্চ চলার সময় আর বাজেটের সীমা এখানে ধরে নেওয়া।

// নিয়মগুলো এই পর্বের সরল সারাংশ; বাস্তবে আরও প্রশ্ন আছে
const FN_MAX_MIN = 5;   // ধরে নেওয়া: platform-এ একটি function সর্বোচ্চ কত মিনিট চলতে পারে
function choose(app) {
  if (!app.nodeServer) return ['shared hosting', 'static export or PHP is enough'];
  const longLived = app.websockets || app.longestJobMin > FN_MAX_MIN;
  if (longLived && app.linuxSkills && app.budgetUsd >= 15)
    return ['VPS + pm2 + proxy', 'long-lived process; you can run Linux'];
  if (longLived && app.budgetUsd >= 40)
    return ['PaaS (web + worker)', 'long-lived process; managed for you'];
  if (longLived) return ['rethink', 'budget too low for long-lived process'];
  if (app.spiky) return ['serverless + pooler', 'bursty traffic; watch DB connections'];
  return app.linuxSkills ? ['VPS + pm2 + proxy', 'steady traffic, cheapest per month']
                         : ['PaaS', 'steady traffic, no server to manage'];
}
const apps = [
  { name: 'catalog only', nodeServer: false },
  { name: 'shop + live chat', nodeServer: true, websockets: true, longestJobMin: 8,
    linuxSkills: true, budgetUsd: 20 },
  { name: 'shop, no ops person', nodeServer: true, websockets: true, longestJobMin: 8,
    linuxSkills: false, budgetUsd: 50 },
  { name: 'Eid flash sale API', nodeServer: true, websockets: false, longestJobMin: 1,
    linuxSkills: false, budgetUsd: 30, spiky: true },
];
for (const a of apps) {
  const [where, why] = choose(a);
  console.log(`${a.name.padEnd(20)} -> ${where.padEnd(20)} (${why})`);
}

১০ · AI-এর যুগে deployment

“আমার Next.js অ্যাপ deploy করার ধাপ লিখে দাও” বললে AI খুব আত্মবিশ্বাসী একটি তালিকা দেয়। সমস্যা হলো, deployment-এর ভুল test-এ ধরা পড়ে না; ধরা পড়ে production-এ, ক্রেতার সামনে। AI-এর সাধারণ ভুলগুলো এই পর্বের বিষয়ের সাথে মিলিয়ে দেখুন:

AI-এর deployment পরামর্শ হাতে পেলে

• প্রতিটি কমান্ড আর option নিজের version-এর অফিসিয়াল নথিতে মিলিয়েছি (Next.js, pm2, Caddy বা Nginx)
• নিজের যন্ত্রে বা staging-এ চালিয়ে আসল আউটপুট দেখেছি, শুধু পড়ে বিশ্বাস করিনি
• কে কোন port-এ শুনছে দেখেছি; শুধু proxy বাইরে খোলা
• Reload চলাকালীন load দিয়ে ব্যর্থ অনুরোধ গুনেছি
• Backup থেকে একবার restore করে দেখেছি
• কোনো secret prompt-এ, config ফাইলে বা repository-তে দিইনি; অপ্রয়োজনীয় package যোগ হয়নি