مسئله: آپلود ویدیو توسط سازندهها و پخش روان برای میلیاردها بیننده با هر کیفیت اینترنت. دو خط لوله کاملاً جدا: Ingest (سنگین، async) و Playback (داغ، CDN محور).
۱-۲) نیازمندی و تخمین
- FR: آپلود، پردازش/کیفیتهای متعدد، پخش تطبیقی، metadata و جستجو، شمارش بازدید.
- NFR: شروع پخش <2s؛ بدون قطعی؛ آپلود تا چند GB مقاوم به قطعی.
- فرض: 500 ساعت ویدیو آپلود در دقیقه؛ نسبت تماشا به آپلود نجومی — Read-Heavy مطلق.
۳) طراحی — خط لوله آپلود
DIAGRAMIngest async
Creator
→
Object Storage — raw
→
Kafka
→
Transcode workers
→
Storage نسخهها → CDN
- آپلود resumable و تکهتکه، مستقیم به Object Storage (URL امضاشده) — از App Server ها رد نمیشود.
- Transcoding: ویدیو به segment های چند-ثانیهای شکسته و هر کدام به چند کیفیت (240p تا 4K) رمز میشود — موازی روی صدها worker از طریق صف؛ وضعیت در DB (uploaded → processing → live).
- خروجی: HLS/DASH — playlist + segment ها؛ پخشکننده هر چند ثانیه کیفیت را با پهنای باند لحظهای عوض میکند (Adaptive Bitrate).
۴) مسیر پخش و عمق
- Playback: کلاینت playlist را میگیرد؛ segment ها از CDN — ویدیوهای داغ در لبهها، دم بلند از origin با کش pull.
- Metadata (عنوان، کانال، آمار): DB جدا + کش سنگین؛ جستجو در Elasticsearch.
- شمارش بازدید: دقیقبودن لحظهای لازم نیست — رویداد به Kafka، تجمیع پنجرهای، بهروزرسانی دورهای. جلوی تقلب: فیلتر و heuristics آفلاین.
- پیشنهاد ویدیو: خط ML جدا — کاندید + رتبه، خوراکش همان رویدادهای تماشا.
به زبان ساده
یوتیوب یعنی سه مسیر جدا: آپلود و پردازش سنگین (تبدیل به کیفیتها)، ذخیره و پخش از CDN نزدیک، و دادهکاوی روی رویدادهای تماشا.
مثال واقعی
وقتی ویدیو آپلود میکنی، فایل اصلی به قطعات میرود و در صف تبدیل به ۴K تا ۱۴۴p مینشیند؛ پخش از سرور لبه نزدیک توست نه از دیتاسنتر اصلی.