শেখো / মৌলিক ধারণা

CDN (Content Delivery Network)

9 মিনিট Module 1 · Fundamentals

এক নজরে

●CDN হলো পৃথিবীজুড়ে ছড়িয়ে থাকা edge server-এর নেটওয়ার্ক, যা ব্যবহারকারীর কাছাকাছি থেকে static content সার্ভ করে।
●মূল লাভ দুটি — কম latency এবং origin server-এর উপর কম চাপ।
●Pull CDN নিজে থেকে content cache করে, Push CDN-এ আপনি আগেই content পাঠিয়ে দেন।

সমস্যাটা কী?

ধরো তুমি ঢাকায় বসে একটা ই-কমার্স ওয়েবসাইট বানিয়েছ, আর তোমার সার্ভার (origin server) আছে ঢাকার একটা ডেটা সেন্টারে। ঢাকার ব্যবহারকারীদের কাছে পেজ খুব দ্রুত লোড হয়। কিন্তু এখন তোমার ওয়েবসাইট জনপ্রিয় হয়ে গেছে — লন্ডন, নিউইয়র্ক, সিডনি থেকেও মানুষ ঢুকছে।

সমস্যা হলো, সিডনির একজন ব্যবহারকারী যখন তোমার ওয়েবসাইটে একটা ৫০০ KB-এর প্রোডাক্ট ছবি লোড করতে চায়, তখন সেই request-কে অর্ধেক পৃথিবী পাড়ি দিয়ে ঢাকায় আসতে হয়, আবার ছবিটা ফিরে যেতে হয়। আলোর গতিও সীমিত — এই দূরত্বে শুধু network latency-ই ২০০–৩০০ ms হয়ে যায়। একটা পেজে যদি ৫০টা ছবি/ফাইল থাকে, ব্যবহারকারী বিরক্ত হয়ে চলে যাবে।

তাছাড়া, সব request যদি একটাই origin server-এ আসে, তাহলে ট্রাফিক বাড়লে সেই সার্ভার ভেঙে পড়বে। এই দুটো সমস্যার একটাই সুন্দর সমাধান — CDN।

মূল ধারণা

CDN (Content Delivery Network) হলো পৃথিবীর বিভিন্ন জায়গায় ছড়িয়ে থাকা সার্ভারের একটা নেটওয়ার্ক, যা ব্যবহারকারীর ভৌগোলিকভাবে কাছের সার্ভার থেকে static content (ছবি, ভিডিও, CSS, JS) ডেলিভারি করে।

মূল আইডিয়াটা সহজ — content-কে ব্যবহারকারীর কাছে নিয়ে যাও, ব্যবহারকারীকে content-এর কাছে পাঠিও না। CDN কোম্পানিগুলো (যেমন Cloudflare, Akamai, AWS CloudFront) পৃথিবীজুড়ে শত শত Edge Server বসিয়ে রাখে। Edge server হলো সেই সার্ভার যা ব্যবহারকারীর কাছাকাছি থাকে এবং তোমার content-এর একটা cache করা কপি রাখে।

যে মূল সার্ভারে তোমার আসল content থাকে, তাকে বলে Origin Server। CDN মূলত origin-এর সামনে একটা স্তর হিসেবে কাজ করে।

কীভাবে কাজ করে

ধাপে ধাপে

ব্যবহারকারী cdn.tomarsite.com/logo.png চায়।
DNS তাকে তার সবচেয়ে কাছের edge server-এ পাঠায় (সিডনির ব্যবহারকারীকে সিডনির edge-এ)।
Edge server দেখে তার কাছে logo.png cache করা আছে কি না।
Cache HIT হলে — সরাসরি edge থেকে ছবিটা ফেরত দেয় (কয়েক ms-এ)।
Cache MISS হলে — edge origin server থেকে ছবিটা টেনে আনে, নিজের কাছে cache করে রাখে, তারপর ব্যবহারকারীকে দেয়। পরের বার আর origin-এ যেতে হয় না।

Latency-র বাস্তব হিসাব

পরিস্থিতি	আনুমানিক latency
সিডনি → ঢাকা origin (কোনো CDN নেই)	২৫০–৩৫০ ms
সিডনি → সিডনি edge (cache HIT)	১০–৩০ ms
Origin server-এ load (CDN আগে)	প্রায় ৭০–৯০% কম

দেখো, latency প্রায় ১০ গুণ কমে যাচ্ছে। বড় সাইটগুলোয় ৮০–৯৫% ট্রাফিক CDN থেকেই সার্ভ হয়, মাত্র ৫–২০% origin-এ পৌঁছায়।

Cache Invalidation

ধরো তুমি logo.png বদলালে, কিন্তু edge server-এ পুরোনো কপি cache করা আছে। ব্যবহারকারী পুরোনোটাই দেখবে। এটা সামলানোর উপায়:

TTL (Time To Live): প্রতিটা cache করা ফাইলে একটা মেয়াদ থাকে (যেমন ২৪ ঘণ্টা)। মেয়াদ শেষ হলে edge আবার origin থেকে fresh কপি আনে।
Cache Purge: তুমি ম্যানুয়ালি CDN-কে বলো নির্দিষ্ট ফাইল মুছে ফেলতে।
Versioned URL: ফাইলের নামে version যোগ করো — logo.v2.png বা style.css?v=123। নতুন নাম মানে নতুন cache, পুরোনোটা আপনাআপনি অকেজো হয়।

সহজ উদাহরণ

ভাবো, একটা জনপ্রিয় বইয়ের শুধু একটাই কপি আছে ঢাকার কেন্দ্রীয় গ্রন্থাগারে (origin)। চট্টগ্রাম, রাজশাহী, সিলেটের পাঠকদের প্রতিবার ঢাকায় আসতে হবে — সময় আর খরচ দুটোই বেশি। এর বদলে যদি প্রতিটা জেলা শহরের লাইব্রেরিতে (edge server) বইটার একটা কপি রাখা হয়, পাঠক হেঁটে গিয়েই পড়তে পারবে। নতুন সংস্করণ এলে শুধু লাইব্রেরিগুলোয় নতুন কপি পাঠাতে হবে — সেটাই cache invalidation।

প্রকারভেদ

CDN মূলত দুই কৌশলে content-কে edge-এ আনে:

১. Pull CDN

এখানে CDN নিজে থেকে origin থেকে content "টেনে আনে" — কিন্তু শুধু যখন কেউ প্রথমবার চায়। প্রথম request-এ cache MISS হয়, edge origin থেকে এনে cache করে; পরের সব request HIT হয়।

সুবিধা: সেটআপ সহজ, শুধু যা চাওয়া হয় তা-ই cache হয়, storage কম লাগে।
অসুবিধা: প্রথম ব্যবহারকারী একটু ধীর গতি পায় (cold cache)। TTL শেষ হলে আবার origin-এ hit হয়।
বেশিরভাগ ওয়েবসাইটের জন্য এটাই ডিফল্ট পছন্দ।

২. Push CDN

এখানে তুমি নিজে আগেভাগেই content edge server-এ "পুশ" করে দাও — কেউ চাওয়ার আগেই।

সুবিধা: কখনো cold cache হয় না, প্রথম ব্যবহারকারীও দ্রুত পায়। বড় ফাইল (সফটওয়্যার ইনস্টলার, ভিডিও) আগে থেকে বিলি করার জন্য ভালো।
অসুবিধা: তোমাকে নিজে content আপলোড ও আপডেট ম্যানেজ করতে হয়। কম পরিবর্তনশীল, বড় ফাইলের জন্য উপযুক্ত।

বৈশিষ্ট্য	Pull CDN	Push CDN
content আসে	চাহিদামতো (প্রথম request)	আগে থেকে আপলোড করা
সেটআপ	সহজ	তুলনামূলক জটিল
প্রথম ব্যবহারকারী	একটু ধীর	দ্রুত
উপযুক্ত	সাধারণ ওয়েবসাইট	বড়, কম-পরিবর্তনশীল ফাইল

কখন ব্যবহার করবে / করবে না

করবে:

যখন তোমার ব্যবহারকারী বিভিন্ন দেশ/অঞ্চলে ছড়ানো।
ছবি, ভিডিও, CSS, JS, ফন্ট — এসব static asset সার্ভ করতে।
origin server-এর load কমাতে এবং DDoS আক্রমণ থেকে কিছুটা সুরক্ষা পেতে।

করবে না (বা সাবধানে):

যে content প্রতি ব্যবহারকারীর জন্য আলাদা (ব্যাংক ব্যালেন্স, ব্যক্তিগত ড্যাশবোর্ড) — এগুলো cache করা বিপজ্জনক।

সাবধান

ভুলেও ব্যক্তিগত বা dynamic content (যেমন লগইন-নির্ভর পেজ, API response যাতে অন্যের ডেটা থাকে) CDN-এ public cache করো না। তাহলে একজন ব্যবহারকারীর তথ্য আরেকজনের কাছে চলে যেতে পারে — এটা মারাত্মক নিরাপত্তা ত্রুটি। সবসময় cache header (Cache-Control: private/no-store) ঠিকমতো সেট করো।

বাস্তব উদাহরণ

Netflix তাদের ভিডিও ডেলিভারির জন্য নিজস্ব CDN বানিয়েছে — নাম Open Connect। তারা ISP-দের ডেটা সেন্টারে সরাসরি তাদের সার্ভার বসিয়ে রাখে, যাতে তোমার দেখা সিনেমাটা তোমার শহরের কাছ থেকেই স্ট্রিম হয়। এতে দূরপাল্লার ব্যান্ডউইথ আর buffering দুটোই কমে। Netflix-এর ভিডিও ট্রাফিকের প্রায় পুরোটাই এই edge cache থেকে আসে।

আবার Cloudflare-এর ৩০০+ শহরে edge server আছে; পৃথিবীর কোটি কোটি ওয়েবসাইট এর পেছনে বসে CDN ও নিরাপত্তা পায়।

টিপস

ইন্টারভিউতে "ছবি/ভিডিও দ্রুত কীভাবে সার্ভ করবে?" জিজ্ঞেস করলে শুধু "CDN ব্যবহার করব" বললেই হবে না। ব্যাখ্যা করো — কোন content cache হবে (static vs dynamic), pull না push, TTL কত, আর cache invalidation কীভাবে করবে (versioned URL সবচেয়ে নিরাপদ)। এটা বললে তুমি অভিজ্ঞ মনে হবে।

মূল শব্দ (Key Terms)

CDN Edge Server Origin Server Cache Invalidation

মিনি কুইজ

1. CDN-এর মূল উদ্দেশ্য কী?

2. Pull CDN আর Push CDN-এর মূল পার্থক্য কী?

3. কোন ধরনের content CDN-এ সবচেয়ে ভালো কাজ করে?

আগের পাঠDatabases পরের পাঠMessage Queues