Live Streaming + Live Chat ডিজাইন

ভাই, শেষ কেসটা সবচেয়ে "ভারী" — Live Streaming + Live Chat। ভাবো একটা ক্রিকেট ম্যাচ লাইভ, ১ কোটি মানুষ দেখছে আর একসাথে কমেন্ট করছে। দুটো আলাদা সিস্টেম একসাথে ডিজাইন করতে হবে।

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

Functional:

• Broadcaster ভিডিও আপলোড (ingest) করবে, লক্ষ ভিউয়ার দেখবে।
• একাধিক quality (ABR) — 240p থেকে 1080p।
• Live chat — ভিউয়াররা রিয়েল-টাইমে মেসেজ পাঠাবে।
• Viewer count দেখা যাবে।
• লাইভ শেষে VOD/replay থাকবে।

Non-functional:

• স্কেল — লক্ষ-কোটি concurrent viewer।
• লো লেটেন্সি — glass-to-glass কয়েক সেকেন্ডের মধ্যে (interactive হলে আরও কম)।
• HA — লাইভ চলাকালীন downtime মানে বিপর্যয়।
• চ্যাট fan-out কম লেটেন্সিতে।

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

ধরি:
- Concurrent viewers: 10M (একটা বড় ইভেন্ট)
- গড় bitrate: 3 Mbps (720p)

video ব্যান্ডউইথ:
- 10M × 3 Mbps = 30 Tbps egress (!!)
- এটাই কেন CDN অপরিহার্য — origin কখনো এত দিতে পারবে না

segment delivery:
- 4 sec segment, প্রতি viewer প্রতি 4 sec-এ একটা request
- 10M / 4 = 2.5M segment req/sec (CDN edge সামলায়)

chat:
- ধরি 1% ভিউয়ার মেসেজ পাঠায়: 100K msg/sec inbound
- কিন্তু fan-out: প্রতি msg 10M কে → 10M × (msg rate দৃশ্যমান) 
- বাস্তবে rate-limit/sampling করে ভিউয়ার-প্রতি কয়েকটা msg/sec দেখানো হয়

storage (VOD):
- 2 hour stream × multi-bitrate ≈ ~5 GB/ladder × ladders

মূল শিক্ষা: ভিডিও egress শুধু CDN দিয়েই সম্ভব; চ্যাট fan-out আলাদা hard problem।

৩. API ডিজাইন

# Ingest (broadcaster)
RTMP/SRT push  →  rtmp://ingest/{streamKey}     # বা WebRTC ingest

# Playback (viewer, HTTP)
GET /live/{streamId}/master.m3u8        → ABR manifest
GET /live/{streamId}/720p/seg_142.ts    → video segment

# Chat (WebSocket)
→ JOIN   { streamId, userId }
→ SEND   { text }
← MSG    { userId, text, ts }           # broadcast
← COUNT  { viewers }                     # periodic

# VOD
GET /vod/{streamId}/master.m3u8

ভিডিও playback ইচ্ছাকৃতভাবে plain HTTP — যাতে যেকোনো CDN cache করতে পারে।

৪. ডেটা মডেল

Entity	Field	ব্যাখ্যা
Stream	streamId, broadcasterId, streamKey, status, startedAt	লাইভ মেটাডেটা
Segment	streamId, quality, seq, url, duration	HLS segment
Manifest	streamId, playlist (m3u8)	dynamic, প্রতি segment-এ আপডেট
ChatMessage	msgId, streamId, userId, text, ts	চ্যাট (ephemeral + sampled persist)
ViewerCount	streamId, count	approximate, in-memory

Choice: ভিডিও segment + manifest → object storage + CDN (immutable file, দারুণ cache hit)। চ্যাট মেসেজ মূলত ephemeral — সব persist করার দরকার নেই; replay-এর জন্য sampled/important মেসেজ একটা append store-এ রাখা যায়। Viewer count approximate (HyperLogLog/sharded counter) — exact দরকার নেই।

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

ভিডিও পাইপলাইন:

Broadcaster (RTMP/SRT)
  → Ingest Server (stream key validate)
  → Transcoder (multi-bitrate ladder: 240/480/720/1080)
  → Segmenter (HLS/DASH: ছোট segment + manifest আপডেট)
  → Object Storage (origin)
  → CDN edge (millions of viewers এখান থেকে pull)
  → Player (ABR: নেটওয়ার্ক বুঝে quality switch)

চ্যাট পাইপলাইন:

Viewer → WebSocket Gateway → Chat Service
  → message validate + rate-limit + moderate
  → publish to Pub/Sub (topic = streamId)
  → সব gateway node subscribe করে → নিজের connected viewer-দের পাঠায়

দুটো পাইপলাইন স্বাধীন — ভিডিও CDN-heavy (HTTP cache), চ্যাট connection-heavy (WebSocket fan-out)।

৬. গভীরে (Deep Dive)

Ingest → Transcode → Segment

Broadcaster RTMP বা SRT দিয়ে একটা সিঙ্গল high-quality stream push করে। Transcoder সেটাকে একাধিক bitrate ladder-এ encode করে (যেমন 1080p/720p/480p/240p) যাতে দুর্বল নেট-ও চলে। Segmenter প্রতিটা ladder-কে ছোট ছোট segment (২-৬ সেকেন্ড) এ কাটে এবং একটা manifest (.m3u8) আপডেট করতে থাকে যেখানে নতুন segment-এর URL যোগ হয়। প্লেয়ার বারবার manifest poll করে নতুন segment টানে।

লেটেন্সি বনাম স্কেল

পদ্ধতি	লেটেন্সি	স্কেল	নোট
HLS/DASH (normal)	~১৫-৩০ সেকেন্ড	বিশাল	CDN cache, সবচেয়ে স্কেলেবল
LL-HLS (low latency)	~২-৫ সেকেন্ড	বড়	partial segment, chunked transfer
WebRTC	১ সেকেন্ডের কম	সীমিত	interactive, কিন্তু fan-out কঠিন

বড় segment = ভালো cache কিন্তু বেশি লেটেন্সি; ছোট segment = কম লেটেন্সি কিন্তু বেশি request। তাই ব্যবহার-কেস বুঝে বাছতে হয়: ক্রিকেট ম্যাচে LL-HLS, ভিডিও কল/অকশনে WebRTC।

Chat fan-out

এক রুমে এক মেসেজ লক্ষ ভিউয়ারের কাছে যেতে হবে। সমাধান:

• Pub/Sub — chat service মেসেজ একটা topic-এ publish করে; সব gateway node subscribe করে নিজের connected viewer-দের পাঠায়।
• Connection sharding — এক gateway ~৫০K কানেকশন; অনেক gateway মিলে লক্ষ কানেকশন।
• Rate limit + sampling — লক্ষ msg/sec কেউ পড়তে পারে না; তাই ভিউয়ার-প্রতি কয়েকটা msg/sec দেখানো হয় (popular/sampled), বাকিগুলো drop।
• Moderation — spam/abuse ফিল্টার fan-out-এর আগে।

Viewer count

Exact count রাখা ব্যয়বহুল। Approximate counter (sharded counter বা HyperLogLog) দিয়ে আনুমানিক সংখ্যা পর্যায়ক্রমে broadcast করা হয় — ভিউয়ারের কাছে ১০,২৩,৪৫৬ আর ১০,২৩,৫০১-এর পার্থক্য মূল্যহীন।

Replay / VOD

লাইভ চলাকালীন তৈরি হওয়া segment-গুলো immutable, তাই লাইভ শেষে সেগুলো জোড়া দিয়েই VOD তৈরি হয়। একটা নতুন static manifest বানিয়ে object storage + CDN থেকেই replay সার্ভ করা যায়।

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

• Video egress — পুরোটাই CDN; multi-CDN + origin shield দিয়ে origin বাঁচাও।
• Transcoding CPU/GPU — ভারী; GPU encoder, per-stream autoscale।
• Thundering herd on manifest — সবাই একসাথে নতুন segment চায়; manifest-এ ছোট cache TTL + CDN coalescing।
• Chat connection scale — gateway horizontal scale, pub/sub sharded by streamId।
• Hot stream — একটা viral stream-এ সবাই; CDN auto-distribute, chat gateway আলাদা পুল।
• Global latency — regional ingest + regional CDN PoP।

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

Live Streaming মানে আসলে দুটো সিস্টেম: (১) ভিডিও পাইপলাইন — ingest → transcode → segment (HLS/DASH) → CDN, যেখানে CDN-ই কোটি ভিউয়ার সামলায়; (২) চ্যাট — pub/sub + connection sharding + sampling দিয়ে best-effort fan-out। লেটেন্সি বনাম স্কেল ট্রেড-অফ বুঝে HLS/LL-HLS/WebRTC বাছো, viewer count approximate রাখো, আর immutable segment থেকেই VOD বানাও।