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

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

প্রতিটা প্রশ্নের উত্তর জানার পর আপনি distance 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 এর উপর চাপ কমেছে। কিন্তু Bangladesh-এ বসানো সব server এর জন্য একটা সমস্যা থেকেই যাচ্ছে।

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

Argentina থেকে Bangladesh round trip ≈ ১২০-১৫০ms। এটা শুধু travel time; server এখনো কিছু করেনি।
একটা page load মানে dozens of request: HTML, CSS, JS, image, font। ৩০টা resource × ১৩০ms মিলে দাঁড়ায় অনেক second।

১২০-১৫০ms এর গণিতঃ

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

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

এটা theoretical minimum। বাস্তবে submarine cable সরলরেখায় যায় না; ocean এর তলদেশে বাঁকা পথে যায়, cable landing station এ থামে। ফলে আসল cable দূরত্ব great circle এর চেয়ে বেশি, আর actual transmission time ১৬০ms এর চেয়েও বেশি। তার উপর প্রতিটা network hop এ routing overhead যোগ হয়। Real-world ping Bangladesh থেকে Argentina তে সাধারণত ২৮০-৩৫০ms এর কাছাকাছি। Session এর source এ "১২০-১৫০ms" টা simplified physics estimate হিসেবে ব্যবহার করা হয়েছে। মূল point একটাই: server কিছু করার আগেই শুধু wire এ চলে যায় বড় একটা সময়।

নতুন ধরনের bottleneck

Server scaling এই latency fix করতে পারে না। Bangladesh এ faster server বসালেও সেই server Bangladesh এই আছে। Fix টা distance নিয়ে, compute নিয়ে না। এটা একটা নতুন ধরনের bottleneck: “Machine ঠিকঠাক, কিন্তু অনেক দূরে।“

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

শুধু DB replica Argentina তে বসালে কাজ হবে না। Request path তখনো এরকম থাকবে: User (Argentina) → App Server (Bangladesh) → DB Replica (Argentina) → App Server (Bangladesh) → User (Argentina)। চারটা বড় crossing।

সত্যিকারের fix হলো multi-region deployment: full app stack (app server + DB একসাথে) একাধিক region এ বসানো। কিন্তু এটা expensive আর complex।

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

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

CDN এর সাথে কাজ শুরুর আগে এই প্রশ্নটা করতেই হবে।

ধরন	উদাহরণ	CDN-able?
Static content: সবার জন্য একই	Image, CSS, JS, font, video	হ্যাঁ। Copy করে worldwide serve করা যায়।
Dynamic content: user-specific	Personalized feed, account balance, cart, search result	না। Application logic দরকার।

বেশিরভাগ site এর মোট bytes এর বড় অংশই static (image, video, CSS, JS, font)। HTML অংশটা ছোট আর dynamic হলেও, static অংশটা বড়। তাই CDN traffic এর সিংহভাগ offload করতে পারে।

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

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

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

CDN (Content Delivery Network): static content এর copy user দের কাছে রাখার জন্য একটা global server network।

দুটো key জায়গা আছে:

Origin server: আপনার real system (Bangladesh)। True copy এখানে আছে। Source of truth।
Edge server (PoP, Point of Presence): CDN এর server, শত শত city তে। Static content এর cached copy ধরে রাখে। “Edge” মানে user দের কাছাকাছি।

Request flow টা Session 04 এর cache-aside pattern এর মতোই, কিন্তু geographically:

HIT (highlighted): Edge Buenos Aires থেকে ~10ms এ serve। MISS (dashed): Edge origin থেকে একবার fetch করে, store করে, পরের সব request এর জন্য ready।

CDN = Geographic Cache

এটা Session 04 এর cache-aside pattern, geographically apply করা। Hit হলে locally serve। Miss হলে origin থেকে একবার fetch, store, পরের সব request এ hit। TTL, eviction, invalidation সহ Session 04 এর সবকিছু এখানে প্রযোজ্য, শুধু planetary scale এ।

Argentina এর fix কীভাবে হয়: static content Buenos Aires থেকে (~10ms) serve হয়, Bangladesh থেকে (~130ms) না। Dozens of resource মানে seconds বাঁচে। Bonus: প্রতিটা edge-served request origin পর্যন্ত পৌঁছায় না, তাই CDN traffic এর বড় অংশ নিজে handle করে নেয়।

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

Edge server content পাওয়ার দুটো পদ্ধতি আছে।

	Pull CDN	Push CDN
কীভাবে কাজ করে	Edge প্রথম request এর সময় origin থেকে নিজে pull করে	আপনি আগে থেকেই edge এ content push করেন, কোনো request আসার আগেই
Setup	কম কাজ। আলাদা কিছু করতে হয় না।	বেশি কাজ। আপনাকে push করতে হয়।
প্রথম user এ cold miss	হ্যাঁ। প্রথম user slow।	না। Pre-loaded।
সবচেয়ে ভালো কখন	General site, unpredictable demand	Large file + predictable big event

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

Netflix রাত ১২টায় blockbuster release করলে Push CDN ব্যবহার করে। আগে থেকে সব edge এ video pre-load করা থাকে। না করলে প্রথম million viewer একসাথে origin hit করবে (Session 04 এর cache stampede এর geographic version)। অন্যদিকে, unpredictable reader এর ছোট blog Pull CDN ব্যবহার করে। Lazy default: যখন demand আসে, তখনই fetch করা হয়।

Pull CDN: lazy default। প্রথম user miss এর cost দেয়, পরের সবাই hit পায়। Push CDN: proactive। Large file এবং predictable spike এর জন্য ideal, cold miss নেই।

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

এটা Session 04 এর cache invalidation problem, global scale এ। তিনটা mechanism আছে।

১. TTL (Expiry)

প্রতিটা cached file এর একটা time-to-live থাকে। Expire হলে পরের request এ edge origin থেকে re-fetch করে। HTTP header দিয়ে set করা হয়: Cache-Control: max-age=3600।

Short TTL: fresh content, কিন্তু বেশি origin traffic।
Long TTL: কম traffic, কিন্তু potentially stale।

TTL expiry edge এর নিজের clock দিয়ে handle হয়। Origin unreachable থাকলে CDN সাধারণত পুরনো copy serve করে (“serve stale on error”)। Failure mode হলো “user একটু পুরনো content পায়”, “forever frozen” না।

২. Purge (Active Invalidation)

CDN কে explicitly বলা হয়: “এই file এখনই সব edge থেকে মুছে ফেলা হোক।” সব জায়গায় re-fetch হয়। TTL শেষ হওয়ার জন্য অপেক্ষা করতে হয় না। গুরুত্বপূর্ণ change এ ব্যবহার হয়। Session 04 এর delete-on-write এর মতো, কিন্তু global edges এ।

৩. Versioned Filenames (Clever Fix)

logo.png in-place update না করে প্রতিটা version নতুন নাম পায়:

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

File বদলালে তার নাম বদলায়। HTML নতুন নামটা reference করে। CDN এর কাছে logo.v2.png brand new, কোনো stale copy নেই, তাই fresh fetch হয়।

কেন এটা elegant

কখনো কিছু invalidate করতে হয় না। New version মানে new URL; new URL মানে automatic cache miss; cache miss মানে fresh fetch। Static file এ very long TTL (forever) set করুন, কারণ বদলালে filename ই বদলে যাবে। তাই বড় production site এর file এ main.4f2a9b.js এর মতো hash দেখবেন (এই 4f2a9b অংশটাই version/hash)।

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

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

একই build step তখন সব HTML এর reference ও automatically update করে দেয়। ধরুন main.js তিনটা page এ reference করা আছে (/, /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 এর উপর নির্ভর করে। দুটো common shape আছে, কিন্তু দুটোতেই HTML cache হয় (short policy তে), আর hashed asset গুলো forever cache হয়।

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

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

Mechanism	কীভাবে কাজ করে	সবচেয়ে ভালো কখন
TTL	Edge নিজের clock দেখে। Time হলে next request এ re-fetch।	Content যেটা একটু stale হলে চলে।
Purge	Explicit command, সাথে সাথে সব edge থেকে মুছে।	এখনই fresh চাই। HTML route, critical update।
Versioned filename	File বদলালে নাম বদলায়। New URL মানে automatic cache miss।	Static asset। Long TTL সম্ভব। Cleanest approach।

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

নিজের CDN build করতে হয় না। Provider এর কাছ থেকে rent করতে হয়।

Major CDN providers: Cloudflare, Amazon CloudFront (AWS), Akamai (সবচেয়ে পুরনো, enterprise), Fastly, Google Cloud CDN, Azure CDN। তারা physical edge server own করে। আপনি configuration manage করেন। প্রতি GB traffic এ pay করেন।

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

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

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

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

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

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

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

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

Step 1: Domain DNS CDN এ point করুন। DNS বদলে দিন।

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

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

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

Step 3: প্রতিটা user কে nearest edge এ পাঠানো হয়, automatically।

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

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

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

একই কাজ (user কে nearest edge এ পাঠানো) দুইভাবে করা যায়:

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

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

Step 4: Caching rules configure করুন। তিন ধরনের content, তিন রকম policy:

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 হয়, কিন্তু আলাদা policy তে

খেয়াল করুন, HTML কে cache করা হয়, কিন্তু long TTL এ না। কারণ HTML টাই নতুন hashed asset এর নাম point করে; HTML stale থাকলে user পুরনো bundle ই পেতে থাকবে। তাই HTML এ short TTL দেওয়া হয় (অথবা deploy এর সাথে purge করা হয়), আর hashed asset এ forever TTL। “cache না” করা শুধু dynamic, per-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 Buenos Aires edge এ route করলো → edge cache check: HIT হলে ~10ms এ serve। MISS হলে origin থেকে একবার fetch, store, serve। Dynamic request (/cart) edge pass-through করে origin এ যায়।

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

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

Lower latency: static content user এর কাছ থেকে serve হয়।
কম origin load: edge গুলো request এর বড় অংশ absorb করে, origin এ চাপ কমে।
Resilience: origin hiccup করলেও edge গুলো cached static content serve করতে পারে (serve-stale)।
DDoS absorption: CDN এর বিশাল capacity attack traffic কে origin এ পৌঁছানোর আগেই soak করে।

Downside গুলো

Dynamic per-user content edge থেকে serve হয় না: feed, cart, balance এখনো origin এ যায়। এটা fix করতে multi-region deployment লাগে, যেটা heavy।
Invalidation এখনো কঠিন: global staleness হলো Session 04 এর problem, planetary scale এ।
Cost: per-gigabyte bandwidth charge।
Rarely-accessed content এ কম উপকার: cold miss হলে পরে hit benefit নেই।

CDN dynamic content fast করে না

Dynamic content globally fast করতে multi-region deployment লাগে। CDN শুধু static content এর distance latency fix করে। এই পার্থক্যটা সবসময় মাথায় রাখুন।

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

টার্ম	মানে
CDN (Content Delivery Network)	Static content এর copy user দের কাছে রাখার জন্য global server network।
Latency	Request পাঠানো থেকে response পাওয়া পর্যন্ত সময়। Distance মূল কারণ।
Static content	সব user এর জন্য একই content। Image, CSS, JS, font। CDN-able।
Dynamic content	User-specific content। Cart, feed, balance। Application logic দরকার। CDN-able না।
Origin server	আপনার real system। True copy এখানে। Source of truth।
Edge server (PoP)	CDN এর server, user দের কাছে। Cached static content serve করে। Point of Presence।
Pull CDN	Edge প্রথম request এ origin থেকে pull করে। Lazy। General site এর জন্য।
Push CDN	Content আগে থেকেই edge এ push করা। Proactive। Large file, predictable spike।
TTL (Time-to-live)	Cache এ কতক্ষণ রাখা যাবে। Expire হলে re-fetch।
Purge	CDN কে explicitly নির্দেশ দেওয়া, এখনই সব edge থেকে মুছে ফেলার জন্য।
Versioned filenames	File বদলালে নাম বদলানো। New URL মানে automatic fresh fetch। Long TTL possible।
geo-DNS / anycast routing	User এর location দেখে nearest edge এ route করার CDN mechanism।
Serve stale on error	Origin unreachable হলে CDN পুরনো copy serve করা। Graceful degradation।
Multi-region deployment	Full app stack (app server + DB) একাধিক region এ বসানো। Dynamic content এর latency fix।
Cloudflare / CloudFront / Akamai / Fastly	Major CDN provider। Physical edge server তারা চালায়। আপনি configuration করেন।

১০ সর্ট সামারী

CDN সেই একটা bottleneck fix করে যেটা server scaling পারে না: physical distance থেকে latency। Static content edge server এ cache করে user এর কাছে নিয়ে যাওয়া হয়।
Static content (সবার জন্য একই) CDN-able; dynamic per-user content origin এ যেতেই হয়। তাই সবার আগের প্রশ্ন: “এখানে কোনটা static?”
CDN হলো cache-aside pattern geographically। Hit, miss, TTL, invalidation সব Session 04 এর মতো, কিন্তু global scale এ। Provider এর কাছ থেকে rent করুন, DNS CDN এ point করুন, origin বলুন, caching rule set করুন।

১১ মনে রাখুন

কিছু bottleneck distance এর, compute এর না। 16,000 km round trip faster server দিয়ে fix হয় না। Content কাছে নিয়ে যাওয়াই একমাত্র fix।
Static vs dynamic প্রথম প্রশ্ন। Static CDN-able; dynamic origin এ যেতে হবে। বেশিরভাগ bytes static, তাই CDN bulk offload করে।
CDN হলো geographic cache। Session 04 এর সবকিছু (hit, miss, TTL, invalidation, cold cache, stampede) এখানেও প্রযোজ্য, শুধু worldwide।
Versioned filename elegant invalidation। কিন্তু সরাসরি requested URL (সব HTML route, fixed URL) এর জন্য TTL বা purge লাগবেই।
Edge ≠ Origin ≠ App server। Edge হলো CDN provider এর cached server; origin হলো আপনার পুরো system; app server হলো সেই origin এর core।
CDN build করতে হয় না, rent করতে হয়। Setup: DNS CDN এ point করুন, origin configure করুন, caching rule দিন; geo-DNS routing automatic।
CDN dynamic content fast করে না। Dynamic globally fast করতে multi-region deployment লাগে।