কেস স্টাডি: ভিডিও স্ট্রিমিং প্ল্যাটফর্ম ডিজাইন করা

১ · রিকোয়ারমেন্ট

লক্ষ্য করুন — এখানে রাইট (আপলোড) তুলনামূলক বিরল কিন্তু ভারী (একটি ভিডিও কয়েক মিনিটের প্রসেসিং দাবি করতে পারে), অথচ রিড (স্ট্রিমিং) অতি ঘন ঘন কিন্তু প্রতিটি ছোট ছোট সেগমেন্ট রিকোয়েস্টে ভাগ — এই অসামঞ্জস্যই আর্কিটেকচারকে দুই ভাগে ভাগ করে দেয়।

২ · ক্যাপাসিটি অনুমান — আপলোড বনাম স্ট্রিম রিড

L02-এর পদ্ধতিতে: ধরি প্রতিদিন ৫,০০,০০০টি নতুন ভিডিও আপলোড হয়, প্রতিটি গড়ে ৫০০ MB (একাধিক রেজোলিউশনে ট্রান্সকোড করার আগের কাঁচা ফাইল)। আর প্রতিদিন ৫০ কোটি (৫০,০০,০০,০০০) ভিডিও-ভিউ হয়, প্রতিটি ভিউ গড়ে ৩ মিনিট স্ট্রিম করে ৫ Mbps গড় বিটরেটে।

uploads_per_day = 500_000
avg_upload_size_mb = 500

upload_storage_per_day_tb = (uploads_per_day * avg_upload_size_mb) / 1_000_000  # MB -> TB

views_per_day = 500_000_000
avg_watch_minutes = 3
avg_bitrate_mbps = 5

# মোট স্ট্রিমিং ব্যান্ডউইথ (বিট) = ভিউ x সেকেন্ড x Mbps
total_watch_seconds_per_day = views_per_day * avg_watch_minutes * 60
total_stream_megabits_per_day = total_watch_seconds_per_day * avg_bitrate_mbps
avg_stream_mbps_across_platform = total_stream_megabits_per_day / (24 * 60 * 60)

print(f"আপলোড স্টোরেজ/দিন: {upload_storage_per_day_tb:,.1f} TB")
print(f"গড় প্ল্যাটফর্ম-ওয়াইড স্ট্রিমিং থ্রুপুট: {avg_stream_mbps_across_platform:,.0f} Mbps")
print(f"গড় থ্রুপুট (Gbps-এ): {avg_stream_mbps_across_platform / 1000:,.1f} Gbps")

৩ · হাই-লেভেল ডিজাইন

আপলোড হওয়া ভিডিও প্রথমে ব্লব স্টোরেজে যায়, তারপর একটি মেসেজ কিউ (L22) একটি অ্যাসিনক্রোনাস ট্রান্সকোডিংTranscodingএকটি ভিডিও ফাইলকে একাধিক রেজোলিউশন/বিটরেটে (240p, 480p, 720p, 1080p) রূপান্তর করা, যাতে প্লেয়ার নেটওয়ার্ক অনুযায়ী বেছে নিতে পারে। জব সারিবদ্ধ করে — এটি একটি ক্লাসিক ব্যাচ-জব ব্যবহার (L24)। প্রতিটি রেজোলিউশন ছোট ছোট সেগমেন্টে ভাগ হয়ে CDN-এ (L20) পুশ হয়। প্লেব্যাকের সময় প্লেয়ার নিকটতম CDN এজ থেকে সেগমেন্ট আনে, প্রতিবার pick_quality() চালিয়ে পরের সেগমেন্টের রেজোলিউশন ঠিক করে।

৪ · ডিপ ডাইভ — অ্যাডাপটিভ বিটরেট কোয়ালিটি সিলেকশন

HLS/DASH-এর মূল ধারণা: ভিডিও একাধিক কোয়ালিটি লেভেলে ছোট সেগমেন্টে (সাধারণত ২-১০ সেকেন্ড) এনকোড করা থাকে। প্লেয়ার ক্রমাগত সাম্প্রতিক ডাউনলোড থ্রুপুট পরিমাপ করে এবং পরবর্তী সেগমেন্ট আনার আগে সিদ্ধান্ত নেয় — বর্তমান উপলব্ধ ব্যান্ডউইথে কোন কোয়ালিটি নিরবচ্ছিন্নভাবে চলবে। নিচের কোড ঠিক এই সিদ্ধান্ত-লজিকটি বাস্তবায়ন করে — উপলব্ধ ব্যান্ডউইথের সর্বোচ্চ কোয়ালিটি বেছে নেয় যার প্রয়োজনীয়তা সেই ব্যান্ডউইথের মধ্যে পড়ে।

# (কোয়ালিটি নাম, প্রয়োজনীয় ব্যান্ডউইথ Mbps) — বাড়ন্ত ক্রমে
quality_levels = [
    ("240p", 0.4),
    ("480p", 1.0),
    ("720p", 2.5),
    ("1080p", 5.0),
]

def pick_quality(available_bandwidth_mbps):
    chosen = quality_levels[0][0]   # ডিফল্ট: সবচেয়ে কম কোয়ালিটি
    for name, required_mbps in quality_levels:
        if required_mbps <= available_bandwidth_mbps:
            chosen = name            # যত বড় লেভেল ফিট হয়, তত ওপরে ওঠে
    return chosen

# একজন দর্শকের ব্যান্ডউইথ সময়ের সাথে ওঠানামা করছে (সিমুলেটেড রিডিং)
bandwidth_sequence_mbps = [6.0, 3.0, 0.8, 0.3, 1.5, 5.5]

print("সময়ের সাথে ব্যান্ডউইথ ও নির্বাচিত কোয়ালিটি:")
for step, bw in enumerate(bandwidth_sequence_mbps, start=1):
    quality = pick_quality(bw)
    print(f"  সেগমেন্ট {step}: ব্যান্ডউইথ {bw} Mbps -> কোয়ালিটি {quality}")

৫ · ট্রেড-অফ

বেশি কোয়ালিটি লেভেল অফার করলে প্লেব্যাক আরও মসৃণভাবে খাপ খায়, কিন্তু প্রতিটি লেভেলের জন্য আলাদা ট্রান্সকোড ও স্টোরেজ খরচ বাড়ে (একটি ভিডিও ৪-৫ গুণ বেশি স্টোরেজ নেয়)। খুব ঘন ঘন কোয়ালিটি বদলানো (প্রতি সেগমেন্টে) দর্শকের কাছে বিরক্তিকর লাগতে পারে, তাই বাস্তব প্লেয়ার সাধারণত কিছুটা "hysteresis" (একবার নামলে দ্রুত না ওঠা) যোগ করে। এবং CDN ছাড়া (L20) — সব ট্রাফিক অরিজিন সার্ভার থেকে সরাসরি সার্ভ করলে — এই থ্রুপুট মাত্রায় অরিজিন তাৎক্ষণিকভাবে সম্পৃক্ত হয়ে যাবে; তাই CDN এখানে অপশনাল অপ্টিমাইজেশন নয়, স্থাপত্যের একটি অপরিহার্য অংশ।