Design a CDN ডিজাইন

ধরো একটা ভিডিও বা ই-কমার্স সাইট পুরো বিশ্বে কোটি কোটি মানুষ দেখছে, আর সব রিকোয়েস্ট যাচ্ছে ঢাকার একটাই অরিজিন সার্ভারে। তাহলে ইউরোপের একজন ব্যবহারকারীকে প্রতিটা ছবির জন্য অর্ধেক পৃথিবী ঘুরে আসতে হবে — latency ভয়াবহ। এই সমস্যার সমাধান CDN (Content Delivery Network)। চলো ইন্টারভিউ ফ্রেমওয়ার্ক ধরে ডিজাইন করি।

১. সমস্যা বোঝা (Requirements)

ফাংশনাল রিকোয়ারমেন্ট:

• স্ট্যাটিক কনটেন্ট (ছবি, ভিডিও, CSS/JS, ফাইল) ব্যবহারকারীর কাছাকাছি থেকে সার্ভ করা।
• কনটেন্ট আপডেট হলে purge/invalidation সাপোর্ট।
• HTTPS (edge-এ TLS টার্মিনেশন)।
• ক্যাশ কন্ট্রোল (TTL, cache headers মান্য করা)।

নন-ফাংশনাল রিকোয়ারমেন্ট:

• খুবই Low latency — ব্যবহারকারীর কাছ থেকে কয়েক দশ মিলিসেকেন্ডে।
• High availability — কোনো একটা PoP পড়ে গেলেও সার্ভিস চলবে।
• বিশাল scale — পিক ট্রাফিক, ভাইরাল কনটেন্ট।
• High hit ratio — অরিজিনে যত কম যায় তত ভালো।

২. স্কেল আন্দাজ (Estimation)

দৈনিক রিকোয়েস্ট        = 100 বিলিয়ন = 10^11/দিন
গড় RPS                = 10^11 / 86,400 ≈ 1.15 মিলিয়ন req/sec
পিক (3x)               ≈ 3.5 মিলিয়ন req/sec

গড় অবজেক্ট সাইজ        ≈ 100 KB
আউটগোয়িং ব্যান্ডউইথ     = 1.15*10^6 * 100KB ≈ 115 GB/sec ≈ 920 Gbps (avg)

টার্গেট hit ratio       = 95%
=> অরিজিন রিকোয়েস্ট     = 5% * 1.15M ≈ 57,500 req/sec (অরিজিন এটুকুই সামলায়)

প্রতি PoP cache সাইজ    ≈ 50 TB SSD (hot content)
PoP সংখ্যা             ≈ 100-200 বিশ্বজুড়ে

মূল শিক্ষা: hit ratio ৯৫% থেকে ৯৯% হলে অরিজিন রিকোয়েস্ট ৫ গুণ কমে যায়। তাই caching efficiency-ই আসল খেলা।

৩. API ডিজাইন

CDN বেশিরভাগই স্ট্যান্ডার্ড HTTP, কিন্তু কন্ট্রোল প্লেনে কিছু API থাকে।

# কনটেন্ট সার্ভিং (ব্যবহারকারী)
GET https://cdn.example.com/assets/img/logo.png
    -> edge PoP রেসপন্ড করে, header-এ:
    Cache-Control: public, max-age=86400
    X-Cache: HIT (অথবা MISS)

# পার্জ / ইনভ্যালিডেশন (কনটেন্ট মালিক)
POST /v1/purge
     body: { "urls": ["/assets/img/logo.png"] }       # single URL purge
POST /v1/purge
     body: { "tag": "product-123" }                    # tag-based purge
POST /v1/prefetch
     body: { "urls": ["/new-video.mp4"] }              # আগেই warm করা

# কনফিগারেশন
PUT  /v1/origin    body: { "host": "origin.example.com", "ttl": 3600 }

৪. ডেটা মডেল

CDN-এ "ডেটা" মানে মূলত cached object আর তার metadata।

উপাদান	কী রাখে	স্টোরেজ
Cached Object	আসল bytes + headers	edge SSD / RAM
Cache Metadata	key, TTL, etag, last-access	edge-এর in-memory index
Routing Map	user → nearest PoP	Anycast + GeoDNS
Purge Log	কোন object invalidate হলো	control plane (pub/sub)

Cache key: সাধারণত scheme + host + path + (নির্বাচিত query/header)। ভুল cache key বানালে hit ratio পড়ে যায় — যেমন প্রতিটা random query param আলাদা key বানালে cache fragmentation হয়।

Eviction পলিসি: edge cache সীমিত, তাই LRU বা LFU দিয়ে কম-ব্যবহৃত object সরানো হয়।

৫. হাই-লেভেল ডিজাইন

কম্পোনেন্ট:

1. Edge Servers (PoP): ব্যবহারকারীর কাছাকাছি, cache রাখে, TLS টার্মিনেট করে।
2. Cache Hierarchy: Edge → Regional (mid-tier) → Origin। edge মিস হলে regional cache, তাও মিস হলে অরিজিন।
3. Origin: আসল কনটেন্টের উৎস (origin server বা origin storage যেমন S3)।
4. Request Routing Layer: Anycast/GeoDNS দিয়ে ব্যবহারকারীকে নিকটতম PoP-এ পাঠায়।
5. Control Plane: কনফিগ, purge, মনিটরিং বিতরণ করে।

রিকোয়েস্ট ফ্লো:

User --DNS/Anycast--> নিকটতম Edge PoP
   Edge cache HIT?  --> হ্যাঁ: সরাসরি রেসপন্ড (দ্রুততম)
                    --> না: Regional cache জিজ্ঞেস করো
   Regional HIT?    --> হ্যাঁ: edge-এ ভরে রেসপন্ড
                    --> না: Origin fetch --> সব স্তরে cache --> রেসপন্ড

এই multi-tier ডিজাইনে অরিজিনে যাওয়ার আগে দুই স্তর ফিল্টার থাকে, ফলে অরিজিন খুব কম চাপ পায়।

৬. গভীরে (Deep Dive)

(ক) রিকোয়েস্ট রাউটিং: Anycast বনাম GeoDNS

দুটো প্রধান কৌশল:

• Anycast: একই IP অনেক PoP থেকে BGP-তে অ্যাডভার্টাইজ করা হয়। ইন্টারনেট রাউটিং নিজে থেকেই প্যাকেট নিকটতম PoP-এ পাঠায়। সুবিধা: দ্রুত failover, সরল। অসুবিধা: routing path বদলালে কানেকশন ভাঙতে পারে (যদিও আধুনিক স্ট্যাকে কম)।
• GeoDNS: DNS resolver-এর অবস্থান দেখে আলাদা IP রিটার্ন করা হয়। সুবিধা: granular কন্ট্রোল। অসুবিধা: DNS caching/TTL-এর কারণে আপডেট ধীর, আর resolver-এর অবস্থান সবসময় ব্যবহারকারীর অবস্থান নয়।

বাস্তবে বড় CDN দুটোই মেশায় — GeoDNS দিয়ে region, তারপর Anycast দিয়ে region-এর ভেতরে।

(খ) Cache Invalidation / Purge

সবচেয়ে কঠিন অংশ, কারণ কনটেন্ট ২০০+ PoP-এ ছড়ানো। তিনটে কৌশল:

1. TTL-based: প্রতিটা object-এ max-age থাকে; মেয়াদ শেষে আপনাআপনি stale, পরের রিকোয়েস্টে রিফ্রেশ। সরল কিন্তু আপডেট তাৎক্ষণিক নয়।
2. Explicit purge: control plane একটা pub/sub দিয়ে সব PoP-কে "এই key মুছে ফেলো" বলে। দ্রুত কিন্তু সব PoP-এ পৌঁছাতে কয়েক সেকেন্ড।
3. Versioned URL: আপডেটেড ফাইলের URL বদলে দাও (logo.v2.png)। তখন invalidation লাগেই না, নতুন URL মানেই নতুন key।

বাস্তবে versioned URL + TTL মিলিয়ে ব্যবহার করাই সবচেয়ে নির্ভরযোগ্য।

(গ) TLS at Edge ও Origin Shield

TLS handshake ব্যয়বহুল; edge-এ টার্মিনেট করলে ব্যবহারকারীর কাছাকাছিই handshake শেষ হয়, RTT কমে। TLS session resumption আর HTTP/2/3 দিয়ে আরও দ্রুত। অরিজিনকে বাঁচাতে একটা origin shield (একটা ডেডিকেটেড mid-tier) রাখা হয় — সব PoP-এর মিস একটা জায়গায় জড়ো হয়, ফলে অরিজিন একই object বারবার আনে না।

৭. বটলনেক ও স্কেলিং

• Low hit ratio: খারাপ cache key বা কম TTL। key নর্মালাইজ করো, vary header সাবধানে ব্যবহার করো।
• Large video files: range request আর chunked caching দিয়ে আংশিক অংশ cache করো; পুরো ফাইল না এনে প্রয়োজনীয় byte-range দাও।
• PoP failover: Anycast-এ একটা PoP পড়লে BGP স্বয়ংক্রিয়ভাবে ট্রাফিক প্রতিবেশী PoP-এ সরায়।
• Cache eviction storm: SSD ভরে গেলে hot object না সরাতে LFU/admission policy (যেমন TinyLFU) ব্যবহার করো।
• Purge fan-out: ২০০ PoP-এ একসাথে purge পাঠানো ব্যয়বহুল; hierarchical pub/sub দিয়ে ছড়াও।

৮. সারসংক্ষেপ

CDN-এর মূল মন্ত্র — কনটেন্টকে ব্যবহারকারীর যত কাছে সম্ভব নিয়ে যাও। সেটা হয় বিশ্বজুড়ে PoP, একটা cache hierarchy (edge → regional → origin), আর স্মার্ট request routing (Anycast + GeoDNS) দিয়ে। সাফল্য মাপা হয় hit ratio দিয়ে, আর সবচেয়ে কঠিন কাজ হলো নির্ভরযোগ্য cache invalidation। edge-এ TLS টার্মিনেট করে latency আরও কমাও, আর origin shield + request coalescing দিয়ে অরিজিনকে বাঁচাও।