CDN ও Geographic Distribution - দূরত্বের Latency কমানো

০০ যে প্রশ্নগুলোর উত্তর খুঁজবো

প্রতিটা প্রশ্নের উত্তর জানার পর আপনি দূরত্বের কারণে আসা latency থেকে শুরু করে production CDN setup পর্যন্ত পুরো বিষয়টা বুঝতে পারবেন।

১ আমরা একটা scalable system বানালাম। Argentina এর user কেন তবুও slow experience পায়?
২ Server গুলো কাছে নিয়ে গেলেই কি সমাধান হয়ে যাবে না?
৩ কোন content user দের কাছে copy করা যায়, আর কোনটা যায় না?
৪ CDN আসলে কী, এবং এটা content কীভাবে serve করে?
৫ CDN content পায় কীভাবে? Pull CDN বনাম Push CDN।
৬ Content বদলে গেলে CDN পুরোনো content serve করা বন্ধ করে কীভাবে?
৭ বাস্তবে CDN কারা চালায়, আর কীভাবে setup করতে হয়?
৮ CDN কী দেয়, আর কী দিতে পারে না?

০১ আমরা একটা scalable system বানালাম। Argentina এর user কেন তবুও slow experience পায়?

আগের session গুলোতে আমরা replica, caching আর sharding দিয়ে একটা শক্তিশালী system তৈরি করেছি। প্রতিটা machine এর উপর চাপ কমেছে। কিন্তু আমাদের সব server Bangladesh এ বসানো। এতে একটা সমস্যা থেকেই যায়।

সমস্যাটা হলো physics। Data আলোর গতিতে চলে, কিন্তু তবুও দূরত্ব বাড়লে সময় বেশি লাগে।

Argentina থেকে Bangladesh এ একবার গিয়ে আবার ফিরে আসতে (round trip) প্রায় ৩০০ms লাগে। এটা শুধু পথের সময়। Server তখনো কোনো কাজ শুরুই করেনি।
একটা page load করতে browser কে অনেকগুলো জিনিস আনতে হয়: HTML, CSS, JS, image, font। ধরুন ৩০টা resource আছে। প্রতিটায় ৩০০ms করে লাগলে মোট ৯ সেকেন্ড। Browser কয়েকটা resource একসাথে আনে, তাই আসল সময় এর চেয়ে কম হয়। তবু কয়েক সেকেন্ড সহজেই চলে যায়।

~৩০০ms কোথা থেকে আসে

Dhaka থেকে Buenos Aires এর দূরত্ব প্রায় ১৬,০০০ km। এটা great circle দূরত্ব, অর্থাৎ পৃথিবীর গোল পৃষ্ঠের উপর দুটো জায়গার মধ্যে সবচেয়ে ছোট পথ। Fiber optic cable এ data আলোর গতির প্রায় ২/৩ বেগে চলে, অর্থাৎ সেকেন্ডে প্রায় ২,০০,০০০ km।

One-way: ১৬,০০০ km ÷ ২,০০,০০০ km/s = ০.০৮s = ~৮০ms
Round trip: ৮০ms × ২ = ~১৬০ms

এটা physics এর দেওয়া সর্বনিম্ন সীমা (theoretical minimum)। বাস্তবে submarine cable সরলরেখায় যায় না। Cable সমুদ্রের তলদেশে ঘুরপথে যায়, আর মাঝে মাঝে landing station এ থামে। তাই আসল পথ great circle এর চেয়ে লম্বা, আর সময়ও ১৬০ms এর বেশি লাগে। তার উপর পথের প্রতিটা network hop (প্রতিটা router) একটু করে সময় যোগ করে। তাই Bangladesh থেকে Argentina তে real-world ping সাধারণত ২৮০-৩৫০ms হয়। এই session এ আমরা হিসাবের সুবিধার জন্য round trip প্রায় ৩০০ms ধরবো। মূল কথা একটাই: server কোনো কাজ শুরু করার আগেই শুধু পথেই এতটা সময় চলে যায়।

নতুন ধরনের bottleneck

Server scaling এই latency কমাতে পারে না। Bangladesh এ আরো দ্রুত server বসালেও সেই server Bangladesh এই থাকে। সমস্যাটা দূরত্বের, হিসাবের ক্ষমতার (compute) না। এটা একটা নতুন ধরনের bottleneck: machine ঠিকঠাক চলছে, কিন্তু user থেকে অনেক দূরে।

০২ Server গুলো কাছে নিয়ে গেলেই কি সমাধান হয়ে যাবে না?

শুধু database replica Argentina তে বসালে কাজ হবে না। তখন request কে এই পথে যেতে হবে: User (Argentina) থেকে App Server (Bangladesh), সেখান থেকে DB Replica (Argentina), আবার App Server (Bangladesh), তারপর User (Argentina)। অর্থাৎ চারবার মহাদেশ পার হতে হবে।

আসল সমাধান হলো multi-region deployment: পুরো application stack (app server আর database একসাথে) কয়েকটা region এ বসানো। কিন্তু এটা অনেক খরচের আর অনেক জটিল।

তাই এর আগে একটা সহজ প্রশ্ন করুন। Page কে যেসব জিনিস slow করছিলো, তার বেশিরভাগই ছিলো static file (image, CSS, JS, font)। এগুলো কি প্রতিটা user এর জন্য আলাদা? না। তাহলে প্রতিবার Bangladesh থেকে এগুলো আনতে হবে কেন?

০৩ কোন content user দের কাছে copy করা যায়, আর কোনটা যায় না?

CDN নিয়ে কাজ শুরুর আগে এই প্রশ্নের উত্তর জানতেই হবে।

ধরন	উদাহরণ	CDN-able?
Static content: সবার জন্য একই	Image, CSS, JS, font, video	হ্যাঁ। Copy করে সারা পৃথিবীতে serve করা যায়।
Dynamic content: প্রতিটা user এর জন্য আলাদা	Personalized feed, account balance, cart, search result	না। প্রতিবার application logic চালাতে হয়।

বেশিরভাগ site এর মোট bytes এর বড় অংশই static (image, video, CSS, JS, font)। HTML অংশটা ছোট, আর সেটা dynamic হতে পারে। কিন্তু static অংশটা অনেক বড়। তাই CDN মোট traffic এর বেশিরভাগটাই origin এর কাঁধ থেকে নামিয়ে নিতে পারে।

কোনো content CDN এ রাখা যাবে কিনা, সেটা বুঝতে একটা প্রশ্নই যথেষ্ট: এই content কি সব user এর জন্য হুবহু একই? হলে এটা static, CDN এ রাখা যায়। না হলে এটা dynamic, এটাকে origin এই থাকতে হবে।

Content	সব user এর জন্য একই?	ধরন
Nike swoosh logo	হ্যাঁ	Static
Main stylesheet	হ্যাঁ	Static
“আপনার জন্য recommendation”	না	Dynamic
Cart item count	না	Dynamic

০৪ CDN আসলে কী, এবং এটা content কীভাবে serve করে?

CDN (Content Delivery Network): সারা পৃথিবীতে ছড়ানো server এর একটা network। এর কাজ হলো static content এর copy user দের কাছাকাছি রাখা।

এখানে দুই ধরনের জায়গা আছে:

Origin server: আপনার নিজের আসল system (Bangladesh)। আসল copy এখানেই থাকে, তাই সঠিক data এর উৎস (source of truth) এটাই।
Edge server (PoP, Point of Presence): CDN এর server, শত শত শহরে বসানো। এগুলো static content এর cached copy রাখে। “Edge” মানে network এর কিনারা, অর্থাৎ user দের কাছাকাছি।

Request কীভাবে চলে, সেটা Session 04 এর cache-aside pattern এর মতোই। পার্থক্য শুধু এটুকু যে cache টা এখন user এর শহরে বসানো:

HIT (highlighted): Buenos Aires edge প্রায় ১০ms এ serve করে। MISS (dashed): edge origin থেকে একবার file আনে, নিজের কাছে রাখে, তারপর serve করে। পরের সব request এর জন্য copy টা ready থাকে।

CDN আসলে একটা Geographic Cache

এটা Session 04 এর cache-aside pattern, শুধু পৃথিবীর নানা জায়গায় বসানো। Edge এ copy থাকলে (hit) edge নিজেই কাছ থেকে serve করে। Copy না থাকলে (miss) edge একবার origin থেকে file টা আনে, নিজের কাছে রাখে, তারপর serve করে। এরপরের সব request hit হয়। TTL, eviction, invalidation সহ Session 04 এর সব নিয়ম এখানেও খাটে। পার্থক্য হলো, এখন এগুলো সারা পৃথিবী জুড়ে চলে।

Argentina এর সমস্যা এভাবে মেটে: static content এখন Buenos Aires থেকে প্রায় ১০ms এ আসে, Bangladesh থেকে প্রায় ৩০০ms এ না। প্রতিটা resource এ প্রায় ২৯০ms বাঁচে। ৩০টা resource হলে কয়েক সেকেন্ড বাঁচে। সাথে একটা বাড়তি লাভও আছে। Edge থেকে serve হওয়া কোনো request origin পর্যন্ত পৌঁছায় না, তাই CDN traffic এর বড় অংশ নিজেই সামলায়।

০৫ CDN content পায় কীভাবে? Pull CDN বনাম Push CDN।

Edge server দুইভাবে content পেতে পারে।

	Pull CDN	Push CDN
কীভাবে কাজ করে	প্রথম request আসার সময় edge নিজে origin থেকে content আনে	কোনো request আসার আগেই আপনি edge এ content পাঠিয়ে রাখেন
Setup	কম কাজ। আলাদা কিছু করতে হয় না।	বেশি কাজ। আপনাকে নিজে content পাঠাতে হয়।
প্রথম user এ cold miss	হ্যাঁ। প্রথম user এর জন্য page slow হয়।	না। Content আগে থেকেই edge এ থাকে।
সবচেয়ে ভালো কখন	সাধারণ site, যেখানে কখন কী চাওয়া হবে বলা যায় না	বড় file, আর আগে থেকে জানা বড় কোনো event

উদাহরণ: Netflix বনাম ছোট blog

Netflix রাত ১২টায় নতুন একটা জনপ্রিয় সিনেমা release করলে Push CDN ব্যবহার করে। Release এর আগেই সব edge এ video টা রেখে দেওয়া হয়। এটা না করলে প্রথম ১০ লাখ দর্শক একসাথে origin এ request পাঠাতো। এটা Session 04 এর cache stampede এরই geographic রূপ। অন্যদিকে একটা ছোট blog এ কখন কে আসবে, বলা যায় না। তাই সেটা Pull CDN ব্যবহার করে। কেউ কিছু চাইলে তখনই edge সেটা আনে।

Pull CDN: এটা lazy পদ্ধতি, আর বেশিরভাগ site এর জন্য এটাই default। প্রথম user কে একটু অপেক্ষা করতে হয় (cold miss), কিন্তু পরের সবাই hit পায়। Push CDN: এখানে content আগেভাগেই edge এ পাঠানো থাকে। বড় file আর আগে থেকে জানা ভিড়ের জন্য এটা সবচেয়ে ভালো, কারণ এতে cold miss হয় না।

০৬ Content বদলে গেলে CDN পুরোনো content serve করা বন্ধ করে কীভাবে?

এটা Session 04 এর cache invalidation problem, অর্থাৎ পুরোনো cached copy কখন সরাতে হবে সেই প্রশ্ন। পার্থক্য হলো, এখানে copy গুলো সারা পৃথিবীতে ছড়ানো। এর তিনটা উপায় আছে।

১. TTL (Expiry)

প্রতিটা cached file এর একটা TTL (time-to-live) থাকে, অর্থাৎ কতক্ষণ সেটা রাখা যাবে। সময় শেষ হলে পরের request এ edge আবার origin থেকে file টা আনে। HTTP header দিয়ে এটা set করা হয়: Cache-Control: max-age=3600।

Short TTL: content বেশি fresh থাকে, কিন্তু origin এ বেশি traffic যায়।
Long TTL: traffic কম যায়, কিন্তু content পুরোনো (stale) থেকে যেতে পারে।

TTL শেষ হলো কিনা, সেটা edge নিজের clock দেখে ঠিক করে। Origin এর সাথে যোগাযোগ করা না গেলে CDN সাধারণত পুরোনো copy টাই serve করতে থাকে (“serve stale on error”)। ফলে সবচেয়ে খারাপ অবস্থায়ও user একটু পুরোনো content পায়। Content চিরদিনের জন্য আটকে থাকে না।

২. Purge (Active Invalidation)

এখানে CDN কে সরাসরি বলা হয়: “এই file টা এখনই সব edge থেকে মুছে ফেলুন।” তারপর সব জায়গায় file টা নতুন করে আনা হয়। TTL শেষ হওয়ার জন্য অপেক্ষা করতে হয় না। গুরুত্বপূর্ণ কোনো পরিবর্তনে এটা ব্যবহার হয়। এটা Session 04 এর delete-on-write এর মতো, শুধু সারা পৃথিবীর edge জুড়ে।

৩. Versioned Filenames (চালাক সমাধান)

logo.png file টা একই নামে বদলে না দিয়ে প্রতিটা নতুন version কে নতুন নাম দেওয়া হয়:

logo.v1.png  →  logo.v2.png
style.abc123.css  →  style.def456.css
main.4f2a9b.js  →  main.9c1e3d.js

File বদলালে তার নামও বদলায়। HTML তখন নতুন নামটা ব্যবহার করে। CDN এর কাছে logo.v2.png একদম নতুন একটা file, এর কোনো পুরোনো copy নেই। তাই edge এটা fresh আনে।

কেন এটা এত পরিষ্কার সমাধান

এখানে কখনো কিছু invalidate করতে হয় না। নতুন version মানে নতুন URL। নতুন URL এর copy edge এ থাকে না, তাই আপনা থেকেই cache miss হয়। আর cache miss হলে edge fresh file আনে। তাই static file এ খুব লম্বা TTL (কার্যত চিরদিন) set করতে পারেন, কারণ file বদলালে নামই বদলে যাবে। এজন্যই বড় production site এ main.4f2a9b.js এর মতো file name দেখবেন। এখানে 4f2a9b অংশটাই version, অর্থাৎ hash।

এই hash কীভাবে তৈরি আর update হয়

এই hash কেউ হাতে লেখে না বা বদলায় না। Build tool (Webpack, Vite এর মতো bundler) build এর সময় প্রতিটা file এর content থেকে hash হিসাব করে, তারপর সেটা filename এ বসায়। File এর content বদলালে hash ও বদলায়। Content না বদলালে hash একই থাকে।

একই build step তখন সব HTML এর ভেতরের reference ও নিজে থেকে update করে দেয়। ধরুন main.js তিনটা page এ ব্যবহার হয় (/, /products, /about)। Build এর পর main.js এর নাম হলো main.9c1e3d.js। Tool টা তিনটা HTML এই এই নতুন নাম বসিয়ে দেয়। আপনাকে হাতে খুঁজে খুঁজে কিছু বদলাতে হয় না।

গুরুত্বপূর্ণ nuance: versioning সব problem মুছে দেয় না

Versioning trick কাজ করে কারণ নতুন version মানে নতুন URL। কিন্তু কিছু URL কখনো বদলানো যায় না: যেগুলো সরাসরি request হয়। User যে URL টাইপ করে, bookmark করে, বা link এ আসে, সেটা একটা contract; বদলালে link ভেঙে যাবে। তাই সব HTML route এর URL fixed (yoursite.com/, /products, /blog/post-123), এগুলো version করা যায় না।

সমস্যাটা কোথায়, একটা deploy দিয়ে দেখুন। ধরুন /products page এর HTML এর ভেতরে এই reference আছে:

/products  (URL fixed, user এই address এ আসে)
   └─ <script src="main.4f2a9b.js">

নতুন JS deploy করলেন। File এর নাম হলো main.9c1e3d.js (নতুন hash)। এই নতুন file টা CDN automatically fresh fetch করবে, কারণ URL নতুন। এ পর্যন্ত ঠিক আছে। কিন্তু HTML কে এখন নতুন নামটা point করতে হবে:

/products  (একই URL)
   └─ <script src="main.9c1e3d.js">   ← HTML এর ভেতরের content বদলালো

HTML এর content বদলালো, কিন্তু এর URL (/products) একই রইলো। তাই CDN এর কাছে এটা পুরোনো cached HTML ই থেকে যায়, যেটা এখনো পুরোনো main.4f2a9b.js point করছে। Versioning এখানে কোনো সাহায্য করলো না। আর এটা শুধু একটা page এর সমস্যা না; প্রতিটা HTML route এ একই সমস্যা, কারণ সবার URL ই fixed।

তাই file দুই ভাগে ভাগ করে দুই রকম strategy লাগান:

Static asset (image, CSS, JS, font): versioned filename + very long TTL। বদলালে filename বদলায়, তাই এমনিতেই fresh।
HTML route (/, /products, ...): short TTL বা active purge। URL fixed, তাই version করা যায় না।

মূল কথা: versioning freshness problem টা এক level উপরে ঠেলে দেয়। HTML যা reference করে (asset গুলো) তার সব fresh হয়ে যায়, কিন্তু HTML নিজে এখনো TTL বা purge দিয়েই fresh রাখতে হয়। Invalidation পুরোপুরি এড়ানো যায় না।

আধুনিক framework এ HTML টা দেখতে কেমন

“HTML route” বলতে ঠিক কী cache হয়, সেটা framework এর উপর নির্ভর করে। দুইটা প্রচলিত ধরন আছে। দুটোতেই HTML cache হয় অল্প সময়ের জন্য, আর hashed asset গুলো cache হয় কার্যত চিরদিনের জন্য।

SPA (React, Angular এর মতো client-side rendering): পুরো application এর জন্য একটাই index.html থাকে। সব route (/products, /about) browser এর ভেতরে JS router সামলায়, আর server প্রতিবার একই index.html ফেরত দেয়। এই index.html এ short TTL বা no-cache (প্রতিবার origin এর সাথে মিলিয়ে নেওয়া) দেওয়া হয়। এর ভেতরের hashed bundle (main.4f2a9b.js) চিরদিনের জন্য cache হয়।
SSR / Static site (Next.js, Astro এর মতো server-rendered): প্রতিটা route এর জন্য আলাদা HTML তৈরি হয়। প্রতিটা HTML page cache হয়, সাধারণত short TTL এ, অথবা deploy এর সময় purge করে। Asset গুলো আগের মতোই versioned থাকে, আর long TTL পায়।

তাই HTML ও cache হয়, শুধু এর নিয়ম আলাদা (short TTL বা purge)। কারণ HTML এর URL বদলায় না, আর নতুন asset এর নাম এই HTML ই বহন করে। SPA তে এই কাজটা একটা index.html এর মধ্যেই সীমাবদ্ধ। SSR বা static site এ প্রতিটা route এ এটা করতে হয়।

Mechanism	কীভাবে কাজ করে	সবচেয়ে ভালো কখন
TTL	Edge নিজের clock দেখে। সময় শেষ হলে পরের request এ আবার আনে।	যে content একটু পুরোনো হলেও চলে।
Purge	সরাসরি command দিয়ে সাথে সাথে সব edge থেকে মুছে ফেলা হয়।	যখন এখনই fresh content চাই। HTML route, জরুরি update।
Versioned filename	File বদলালে নাম বদলায়। নতুন URL মানেই আপনা থেকে cache miss।	Static asset। Long TTL দেওয়া যায়। সবচেয়ে পরিষ্কার উপায়।

০৭ বাস্তবে CDN কারা চালায়, আর কীভাবে setup করতে হয়?

নিজের CDN বানাতে হয় না। কোনো provider এর কাছ থেকে ভাড়া নিতে হয়।

বড় CDN provider: Cloudflare, Amazon CloudFront (AWS), Akamai (সবচেয়ে পুরোনো, বড় প্রতিষ্ঠানগুলো ব্যবহার করে), Fastly, Google Cloud CDN, Azure CDN। Edge server গুলোর মালিক তারাই। আপনি শুধু configuration ঠিক করেন, আর প্রতি GB traffic এর জন্য টাকা দেন।

তিনটা জায়গার পার্থক্য: Edge, Origin, App server

এই তিনটা term প্রায়ই গুলিয়ে যায়। চলুন পার্থক্যটা পরিষ্কার করে নিই।

Edge server: CDN provider এর machine, user দের কাছাকাছি বসানো। এটা আপনার static content এর cached copy রাখে আর দ্রুত serve করে। এটা stateless, অর্থাৎ নিজের কোনো আসল data রাখে না। আপনি এটা ভাড়া নেন, নিজে চালান না।
Origin: আপনার নিজের পুরো system। আগের session গুলোতে যা বানিয়েছেন, তার সবটাই এর মধ্যে পড়ে (load balancer, app server, cache, shard, replica)। এটা user দের থেকে দূরে থাকে, আর আসল data এর উৎস এটাই। Edge এর কাছে cached copy না থাকলে edge এই origin থেকেই আনে।
App server: origin এর ভেতরের একটা নির্দিষ্ট machine, যেটা আপনার application code চালায়। এটা origin এর একটা অংশ মাত্র, পুরো origin না।

মূল কথা: origin মানে আপনার গোটা system, আর app server সেই system এর ভেতরের একটা অংশ। অর্থাৎ app server origin এর ভেতরেই থাকে:

Origin (আপনার পুরো system)
   ├─ Load Balancer
   ├─ App Server   ← আপনার code এখানে চলে
   ├─ Cache
   └─ Shard + Replica + Backup

"CDN origin থেকে fetch করে" মানে কী

এর মানে CDN আপনার পুরো system এর কাছে ফিরে যায়, আর আপনার load balancer দিয়ে ঢোকে। সেখান থেকে request তার স্বাভাবিক পথে app server পর্যন্ত পৌঁছায়। তাই “origin” আর “app server” এক জিনিস না। Origin বড়, আর app server তার ভেতরের একটা অংশ।

উদাহরণ: myshop.com এর CDN setup (Origin: Bangladesh)

শুরুর আগে একটা জিনিস জেনে নিন। DNS (Domain Name System) হলো ইন্টারনেটের phonebook। আপনি browser এ myshop.com লিখলে browser প্রথমে DNS কে জিজ্ঞেস করে: “এই নামের server এর address (IP) কী?” DNS একটা address ফেরত দেয়। তারপর browser সেই address এ request পাঠায়। অর্থাৎ DNS নাম থেকে address বের করে দেয়।

Step 1: Domain এর DNS CDN এর দিকে ঘুরিয়ে দিন। অর্থাৎ DNS এ address টা বদলে দিন।

আগে: myshop.com  →  [আপনার origin IP, Bangladesh]
পরে: myshop.com  →  [CDN এর network]

এখন থেকে প্রতিটা request আগে CDN এ যায়।

Step 2: CDN কে origin এর address জানিয়ে দিন। CDN dashboard এ লিখে দিন: “আমার origin Bangladesh এ, এই address এ আছে। Cache miss হলে এখান থেকেই content আনতে হবে।”

Step 3: এরপর প্রতিটা user নিজে থেকেই সবচেয়ে কাছের edge এ পৌঁছে যায়। এটা কীভাবে হয়, দেখুন।

সাধারণ DNS সবাইকে একই address দেয়। কিন্তু geo-DNS হলো একটা বিশেষ DNS। User কোন জায়গা থেকে জিজ্ঞেস করছে, সেটা দেখে এটা আলাদা আলাদা address ফেরত দেয়। Argentina থেকে কেউ myshop.com খুঁজলে geo-DNS তাকে Buenos Aires edge এর address দেয়। Tokyo এর user কে দেয় Tokyo edge এর address। ফলে প্রত্যেকে নিজের সবচেয়ে কাছের edge এ পৌঁছে যায়।

geo-DNS আর anycast: একই লক্ষ্য, দুই উপায়

User কে সবচেয়ে কাছের edge এ পাঠানোর কাজটা দুইভাবে করা যায়:

geo-DNS: DNS উত্তর দেওয়ার সময় user এর location দেখে আলাদা edge এর address ফেরত দেয়। অর্থাৎ নাম থেকে address বের করার ধাপেই সিদ্ধান্ত হয়ে যায়।
Anycast routing: অনেকগুলো edge একই IP address ব্যবহার করে। User সেই IP তে request পাঠালে ইন্টারনেটের routing ব্যবস্থা নিজেই request টা সবচেয়ে কাছের edge এ পৌঁছে দেয়।

এই দুটোর যেকোনো একটা (বা দুটো মিলিয়ে) CDN provider নিজেই সামলায়। আপনাকে কিছু করতে হয় না।

Step 4: Caching rule ঠিক করুন। তিন ধরনের content এর জন্য তিন রকম নিয়ম:

Hashed asset:     /*.js  /*.css  /images/*   → cache forever (long TTL)
                  (filename এ hash আছে, বদলালে নাম বদলায়)
HTML:             /  /products  /index.html  → short TTL বা purge-on-deploy
                  (URL fixed, version করা যায় না; তাই fresh রাখতে short TTL)
Dynamic:          /api/*  /cart  /account    → cache না, origin এ pass-through

HTML ও cache হয়, কিন্তু আলাদা নিয়মে

খেয়াল করুন, HTML ও cache করা হয়, কিন্তু long TTL এ না। কারণ নতুন hashed asset এর নাম HTML এর ভেতরেই লেখা থাকে। HTML পুরোনো থাকলে user পুরোনো bundle ই পেতে থাকবে। তাই HTML এ short TTL দেওয়া হয় (অথবা deploy এর সাথে purge করা হয়), আর hashed asset এ চিরদিনের TTL। একদম cache না করার নিয়ম শুধু dynamic, প্রতিটা user এর আলাদা content এর জন্য।

User প্রথমে geo-DNS কে জিজ্ঞেস করে, geo-DNS তাকে nearest edge এ পাঠায় (Argentina → Buenos Aires, UK → London, Japan → Tokyo)। Edge static content serve করে। শুধু cache miss বা dynamic request origin এ পৌঁছায় (dashed arrows)। Origin এর ভেতরে full stack: load balancer, app server, cache, shard।

End-to-end flow: Browser myshop.com/images/logo.png চাইলো। CDN এর geo-DNS request টা Buenos Aires edge এ পাঠালো। Edge তার cache দেখলো। File থাকলে (HIT) edge প্রায় ১০ms এ serve করে। না থাকলে (MISS) edge একবার origin থেকে file টা আনে, নিজের কাছে রাখে, তারপর serve করে। আর dynamic request (যেমন /cart) edge এ থামে না, সোজা origin এ চলে যায়।

০৮ CDN কী দেয়, আর কী দিতে পারে না?

CDN আপনাকে কী দেয়

Lower latency: static content user এর কাছের edge থেকে serve হয়।
কম origin load: বেশিরভাগ request edge গুলো নিজেরাই serve করে, তাই origin এ চাপ কমে।
Resilience: origin কিছুক্ষণের জন্য সাড়া না দিলেও edge গুলো cached static content serve করতে পারে (serve stale on error)।
DDoS absorption: DDoS attack মানে অনেক machine থেকে একসাথে ভুয়া request পাঠিয়ে server কে অচল করার চেষ্টা। CDN এর বিশাল capacity এই traffic কে origin এ পৌঁছানোর আগেই edge এ আটকে দেয়।

Downside গুলো

Dynamic per-user content edge থেকে serve হয় না: feed, cart, balance এখনো origin এ যায়। এটা ঠিক করতে multi-region deployment লাগে, যেটা অনেক খরচের আর জটিল।
Invalidation এখনো কঠিন: পুরোনো copy সরানোর সেই Session 04 এর problem টাই এখন সারা পৃথিবীর edge জুড়ে সামলাতে হয়।
Cost: প্রতি GB bandwidth এর জন্য টাকা দিতে হয়।
কম চাওয়া content এ লাভ কম: যে file খুব কম চাওয়া হয়, পরের request আসার আগেই edge থেকে তার copy সরে যায় (TTL শেষ বা eviction)। তাই প্রায় প্রতিটা request cold miss হয়, আর CDN থেকে লাভ হয় না।

CDN dynamic content fast করে না

Dynamic content সারা পৃথিবীতে দ্রুত করতে multi-region deployment লাগে। CDN শুধু static content এর দূরত্বের latency কমায়। এই পার্থক্যটা সবসময় মাথায় রাখুন।

০৯ মগজে প্রেশার দিন

আগে নিজে ভাবুন। তারপর দেখুন: সবাই যেভাবে ভাবে, কেন সেটা অসম্পূর্ণ, আর আসল insight টা কোথায়।

প্রশ্ন ১: myshop.com এর একটা product page এ আছে product এর ছবি, দাম, আর "আপনার cart এ ৩টা item"। এর কোন কোন অংশ CDN এ cache করবেন?

উত্তর দেখুন আগে নিজে ভাবুন

সবাই যেভাবে ভাবে

“পুরো page টাই CDN এ cache করে দিই। তাহলে Argentina এর user সবকিছু ১০ms এ পাবেন।”

শুনতে ভালো লাগে। কিন্তু এতে একটা বিপজ্জনক bug তৈরি হয়।

কেন এই উত্তর ভুল

Cart এর সংখ্যাটা প্রতিটা user এর জন্য আলাদা। পুরো page cache করলে edge প্রথম user এর page টাই রেখে দেয়। পরের সবাই সেই একই page পান। ফলে প্রথম user এর cart এ ৩টা item থাকলে, যিনি কিছুই কেনেননি তিনিও দেখবেন “৩টা item”। এটা শুধু ভুল তথ্য না, একজনের data আরেকজনের কাছে চলে যাওয়ার ঘটনাও।

সঠিক উত্তর

প্রতিটা অংশকে আলাদা করে সেই একটা প্রশ্ন করুন: এটা কি সব user এর জন্য হুবহু একই?

Product এর ছবি: সবার জন্য একই, আর সহজে বদলায় না। Versioned filename দিয়ে long TTL এ CDN এ রাখুন।
দাম: সবার জন্য একই, কিন্তু sale এর সময় বদলায়। এটা খুব short TTL এ cache করা যায়, অথবা origin থেকে আনা যায়।
Cart এর সংখ্যা: প্রতিটা user এর আলাদা। এটা কখনো cache করবেন না। Browser এটা origin থেকে আলাদা request এ আনবে।

প্রশ্ন ২: আপনি নতুন logo deploy করলেন। CDN purge ও চালালেন। তবুও কিছু user এখনো পুরোনো logo দেখছেন। কেন?

উত্তর দেখুন আগে নিজে ভাবুন

সবাই যেভাবে ভাবে

“Purge ঠিকমতো কাজ করেনি। আরেকবার purge চালালেই ঠিক হয়ে যাবে।”

Purge আসলে ঠিকই কাজ করেছে। সমস্যাটা অন্য জায়গায়।

যে জায়গাটা সবাই miss করে

Cache-Control: max-age header শুধু edge মানে না, user এর browser ও মানে। Browser নিজের কাছেও file টার একটা copy রেখে দেয়। Purge শুধু CDN এর edge থেকে file মুছে দেয়। User এর browser এ যে copy আছে, CDN সেখানে পৌঁছাতে পারে না। তাই TTL শেষ না হওয়া পর্যন্ত সেই user পুরোনো logo ই দেখতে থাকেন।

সঠিক উপায়

একই নামে file বদলাবেন না। Versioned filename ব্যবহার করুন: logo.png এর বদলে logo.v2.png। HTML এর TTL short রাখুন, তাহলে browser তাড়াতাড়ি নতুন HTML পায়। নতুন HTML নতুন নামটা চায়। নতুন নামের কোনো পুরোনো copy edge এও নেই, browser এও নেই। তাই সবাই নতুন logo পান, আর কিছু purge করার দরকারও পড়ে না।

প্রশ্ন ৩: Argentina এর user রা বলছেন, checkout এ "Pay" চাপার পর অনেক সময় লাগে। একজন বললেন, "CDN লাগান, সব fast হয়ে যাবে।" আপনি কী বলবেন?

উত্তর দেখুন আগে নিজে ভাবুন

সবাই যেভাবে ভাবে

“CDN মানেই fast। তাই CDN লাগালে checkout ও fast হবে।”

এখানেই সবচেয়ে বড় ভুল বোঝাবুঝি।

কেন এই উত্তর অসম্পূর্ণ

“Pay” চাপলে একটা dynamic request যায়। এতে order তৈরি হয়, stock কমে, payment হয়। এর উত্তর প্রতিটা user এর জন্য আলাদা, তাই edge এটা cache করতে পারে না। Request টাকে Bangladesh এর origin পর্যন্ত যেতেই হয়। ফলে দূরত্বের সেই প্রায় ৩০০ms round trip থেকেই যায়।

সঠিক ভাবনা

আগে মেপে দেখুন, সময়টা কোথায় যাচ্ছে।

Checkout page এর CSS, JS, image: এগুলো static। CDN এগুলো fast করবে, তাই page তাড়াতাড়ি খুলবে।
“Pay” এর request: এটা dynamic। CDN এর মূল সময়টা কমাতে পারে না। এটা fast করতে origin কে user এর কাছে আনতে হয়, মানে multi-region deployment। অথবা একটা কাজের জন্য কয়েকবার round trip না করে একবারেই শেষ করতে হয়।

মূল শিক্ষা

CDN দূরত্বের সমস্যা মেটায়, কিন্তু শুধু static content এর জন্য। Dynamic request এর দূরত্ব কমাতে origin কেই কাছে আনতে হয়।

১০ যে টার্মগুলো শিখলাম

টার্ম	মানে
CDN (Content Delivery Network)	Static content এর copy user দের কাছে রাখার জন্য সারা পৃথিবীতে ছড়ানো server network।
Latency	Request পাঠানো থেকে response পাওয়া পর্যন্ত সময়। দূরত্ব এর একটা বড় কারণ।
Static content	সব user এর জন্য একই content, যেমন image, CSS, JS, font। CDN এ রাখা যায়।
Dynamic content	প্রতিটা user এর জন্য আলাদা content, যেমন cart, feed, balance। Application logic লাগে, তাই CDN এ রাখা যায় না।
DNS	ইন্টারনেটের phonebook। Domain name থেকে server এর IP address বের করে দেয়।
Origin server	আপনার নিজের আসল system। আসল copy এখানে থাকে, তাই এটাই source of truth।
Edge server (PoP)	CDN এর server, user দের কাছে বসানো। Cached static content serve করে। PoP মানে Point of Presence।
Pull CDN	প্রথম request এ edge নিজে origin থেকে content আনে। সাধারণ site এর জন্য default।
Push CDN	Content আগে থেকেই edge এ পাঠিয়ে রাখা। বড় file আর আগে থেকে জানা ভিড়ের জন্য।
TTL (Time-to-live)	Cache এ কতক্ষণ রাখা যাবে। সময় শেষ হলে আবার আনা হয়।
Purge	CDN কে সরাসরি বলা, যাতে এখনই সব edge থেকে file টা মুছে ফেলে।
Versioned filenames	File বদলালে নাম বদলানো। নতুন URL মানেই আপনা থেকে fresh content। Long TTL দেওয়া যায়।
geo-DNS / anycast routing	User কে সবচেয়ে কাছের edge এ পাঠানোর দুইটা CDN কৌশল।
Serve stale on error	Origin এর সাথে যোগাযোগ না হলে CDN পুরোনো copy serve করে, যাতে site পুরো বন্ধ না হয়।
Multi-region deployment	পুরো application stack (app server আর database) কয়েকটা region এ বসানো। Dynamic content এর latency কমাতে লাগে।
Cloudflare / CloudFront / Akamai / Fastly	বড় CDN provider। Edge server তারা চালায়, আপনি শুধু configuration ঠিক করেন।

১১ শর্ট সামারি

CDN এমন একটা bottleneck ঠিক করে, যেটা server scaling পারে না: দূরত্বের কারণে আসা latency (Argentina থেকে Bangladesh এ round trip প্রায় ৩০০ms)। Static content edge server এ cache করে user এর কাছে নিয়ে যাওয়া হয়, তখন সেটা প্রায় ১০ms এ আসে।
Static content (সবার জন্য একই) CDN এ রাখা যায়। Dynamic, প্রতিটা user এর আলাদা content কে origin এ যেতেই হয়। তাই সবার আগের প্রশ্ন: “এখানে কোনগুলো static?”
CDN হলো সারা পৃথিবীতে ছড়ানো একটা cache-aside। Hit, miss, TTL, invalidation সবই Session 04 এর মতো, শুধু global পরিসরে। Provider এর কাছ থেকে ভাড়া নিন, DNS CDN এর দিকে ঘুরিয়ে দিন, origin জানিয়ে দিন, আর caching rule ঠিক করুন।

১২ মনে রাখুন

কিছু bottleneck দূরত্বের, compute এর না। Bangladesh থেকে Argentina একদিকেই প্রায় ১৬,০০০ km। এই দূরত্ব দ্রুত server দিয়ে কমে না। Content কাছে নিয়ে যাওয়াই একমাত্র উপায়।
Static না dynamic, এটাই প্রথম প্রশ্ন। Static content CDN এ রাখা যায়; dynamic content কে origin এ যেতে হয়। বেশিরভাগ bytes static, তাই CDN বেশিরভাগ traffic নিজেই সামলায়।
CDN হলো geographic cache। Session 04 এর সবকিছু (hit, miss, TTL, invalidation, cold cache, stampede) এখানেও খাটে, শুধু সারা পৃথিবী জুড়ে।
Versioned filename দিয়ে invalidation সবচেয়ে সহজ। কিন্তু যে URL সরাসরি চাওয়া হয় (সব HTML route, fixed URL), তার জন্য TTL বা purge লাগবেই।
Edge, origin আর app server তিনটা আলাদা জিনিস। Edge হলো CDN provider এর cached server। Origin হলো আপনার পুরো system। App server সেই origin এর ভেতরের একটা অংশ।
CDN বানাতে হয় না, ভাড়া নিতে হয়। Setup: DNS CDN এর দিকে ঘুরিয়ে দিন, origin জানিয়ে দিন, caching rule দিন। Geo-DNS routing নিজে থেকেই হয়।
CDN dynamic content fast করে না। Dynamic content সারা পৃথিবীতে দ্রুত করতে multi-region deployment লাগে।