تصميم معمارية رفع ومعالجة وبث الفيديو التكيفي (HLS/DASH)
معمارية شاملة لرفع ملفات الفيديو الضخمة، معالجتها عبر طوابير تحويل التنسيق FFmpeg، وتوزيعها عبر بروتوكول HLS وشبكات التوصيل السريع CDN.
🎥 تصميم نظام رفع وتشغيل الفيديوهات — سؤال انترفيو
المطلوب مش إنك تعمل Upload API.
المطلوب إنك تفكر إزاي تبني Video Platform تتحمل فيديوهات ضخمة ومستخدمين كتير.
📚 المحتويات
- السؤال
- الإجابة السريعة
- 1. أين نخزن الفيديو؟
- 2. لماذا Object Storage؟
- 3. لماذا لا يمر الفيديو عبر Backend؟
- 4. Direct Upload
- 5. Resumable Upload
- 6. TUS Protocol
- 7. Security أثناء الرفع
- 8. بعد اكتمال الرفع
- 9. Transcoding
- 10. Adaptive Bitrate Streaming
- 11. HLS و DASH
- 12. Video Deduplication
- 13. Processing Pipeline
- 14. Webhooks
- 15. CDN
- 16. حماية الفيديو المدفوع
- 17. Signed URLs و Playback Tokens
- 18. DRM
- 19. هل DRM يمنع تسجيل الشاشة؟
- 20. Scale و Cost Optimization
- 21. Observability
- 22. Architecture كاملة
- 23. سيناريو عملي
- 24. أسئلة الانترفيو الحقيقية
- 25. أهم Trade-offs
- الخلاصة
- مصادر
🎯 السؤال
المطلوب تعمل Feature لرفع الفيديوهات في منصة تعليمية.
المدرس يرفع فيديو.
والطالب يشوفه — زي Udemy مثلًا.
إيه اللي هيحصل؟
الإجابة السريعة:
Frontend
↓
Upload API
↓
Storage
↓
Return URL
شكلها سهلة.
لكن في نظام حقيقي، التصميم أقرب إلى:
Teacher
│
▼
Frontend
│
│ 1. Request upload permission
▼
Backend
│
│ 2. Create signed upload URL
▼
Object Storage / Video Platform
│
│ 3. Direct / Resumable Upload
▼
Raw Video
│
│ 4. Processing Job
▼
Queue
│
▼
Video Processing
│
├── Validation
├── Transcoding
├── Thumbnails
├── Captions
└── Packaging
│
▼
HLS / DASH
│
▼
CDN
│
▼
Student
وده هو الفرق بين:
File Upload
و:
Video Platform
1. أين نخزن الفيديو؟
أول سؤال في System Design:
الفيديو هيتخزن فين؟
عندك اختيارات:
| الحل | مناسب لـ | المشكلة الأساسية |
|---|---|---|
| Database | ملفات صغيرة / حالات خاصة | الحجم والـ backup |
| Local Disk | مشاريع صغيرة | scalability ضعيفة |
| Shared File Server | أنظمة محدودة | إدارة وبنية إضافية |
| Object Storage | أنظمة كبيرة | يحتاج تصميم للـ access والـ lifecycle |
| Video Platform | منصات فيديو | تكلفة واعتماد على provider |
أمثلة Object Storage:
- Amazon S3
- Azure Blob Storage
- Google Cloud Storage
وأمثلة Video Platforms:
- Cloudflare Stream
- Mux
- خدمات مبنية فوق AWS / Azure / Google Cloud
2. لماذا Object Storage؟
تخيل عندك:
1,000 teachers
وكل مدرس بيرفع:
20 videos
وفي المتوسط الفيديو:
2 GB
أنت ممكن توصل لعشرات التيرابايت بسرعة جدًا.
تخزين الفيديو داخل Application Server يعمل مشاكل في:
- Disk capacity
- Backups
- Deployments
- Replication
- Scaling
- Failure recovery
أما Object Storage فمصمم أصلًا لتخزين ملفات ضخمة على نطاق كبير.
3. لماذا لا يمر الفيديو عبر Backend؟
تخيل فيديو:
20 GB
لو عملت:
Frontend
↓
Backend
↓
Storage
فأنت بتخلي الـ Backend يمرر 20 GB من البيانات.
وده يضغط على:
- Network bandwidth
- Network throughput
- CPU
- Connections
- Infrastructure cost
- Scalability
الأفضل غالبًا:
Frontend
│
│ ask permission
▼
Backend
│
│ signed upload URL
▼
Frontend
│
│ upload directly
▼
Object Storage
يعني الـ Backend مسؤول عن authorization والـ metadata، وليس نقل كل bytes الخاصة بالفيديو.
Amazon S3 يدعم Presigned URLs بحيث يستطيع العميل رفع object بدون امتلاك AWS credentials مباشرة، والصلاحيات تكون محدودة بما سمح به منشئ الرابط.
4. Direct Upload
الفكرة:
POST /videos/upload-session
الـ Backend يتأكد:
User authenticated?
Teacher?
Course belongs to teacher?
Quota available?
File size allowed?
Content type allowed?
ثم ينشئ:
{
"videoId": "vid_123",
"uploadUrl": "https://...",
"expiresAt": "..."
}
والـ Frontend يرفع مباشرة.
مهم: الـ Upload URL مش لازم يكون URL دائم. الأفضل يكون محدود الصلاحيات والمدة والاستخدام حسب الـ provider.
5. Resumable Upload
دلوقتي مشكلة:
الفيديو:
10 GB
والـ Internet فصل عند:
95%
هل نبدأ من الصفر؟
❌ لا.
في الأنظمة الكبيرة نستخدم:
Resumable Upload
أو:
Multipart / Chunked Upload
الفيديو يتقسم لأجزاء:
Chunk 1
Chunk 2
Chunk 3
...
Chunk 200
مثلاً:
50 MB لكل Chunk
لو حصل failure:
Chunk 1 ✅
Chunk 2 ✅
Chunk 3 ✅
...
Chunk 178 ❌
نبدأ من:
Chunk 178
بدل ما نعيد 177 chunks.
HTTP Range Requests مفيدة في التعامل مع أجزاء من الموارد الكبيرة، لكن Range Requests الخاصة بالتحميل/التشغيل ليست هي نفسها بروتوكول رفع resumable مثل TUS.
6. TUS Protocol
TUS هو بروتوكول مفتوح للـ resumable uploads.
الفكرة الأساسية:
Create Upload Session
↓
Upload chunks
↓
Track uploaded offset
↓
Resume after failure
مثلاً:
Upload ID:
upload_abc123
Uploaded:
4.7 GB
Total:
10 GB
لو:
Browser closed
أو:
Internet disconnected
أو:
Device restarted
يقدر الـ client يكمل بدل ما يبدأ من الصفر.
Cloudflare Stream، مثلًا، يدعم Direct Creator Uploads باستخدام TUS، ويوصي به للملفات الكبيرة أو الاتصالات غير الموثوقة. citeturn0search0turn0search1
7. Security أثناء الرفع
هل أي شخص يقدر يطلب Upload URL؟
طبعًا لا.
لازم عند إنشاء الـ upload session تتحقق من:
| Check | الهدف |
|---|---|
| Authentication | المستخدم مسجل دخول |
| Authorization | عنده صلاحية الرفع |
| Course ownership | المدرس يملك الكورس |
| File size | منع الملفات الضخمة جدًا |
| Duration | منع فيديوهات غير منطقية |
| Allowed formats | تقليل الملفات غير المطلوبة |
| Quota | منع استنزاف التخزين |
| Expiration | انتهاء صلاحية رابط الرفع |
| Rate limit | منع abuse |
| Upload count | منع flood |
مثال:
Teacher
↓
POST /videos/upload-session
↓
Authorization
↓
Quota Check
↓
Validation
↓
Create Upload Session
↓
Return Signed URL
Never Trust The Client.
حتى لو الـ Frontend قال:
type = video/mp4
size = 20MB
ده مش كفاية وحده.
لازم الـ backend/provider pipeline يتحقق من الملف الحقيقي بعد وصوله.
8. بعد اكتمال الرفع
الفيديو اترفع.
هل أصبح جاهز للمشاهدة؟
غالبًا:
❌ لا
لأن عندك Processing Pipeline.
ممكن تحتاج:
Upload
↓
Validation
↓
Metadata Extraction
↓
Transcoding
↓
Thumbnail Generation
↓
Caption Processing
↓
Packaging
↓
Encryption
↓
Ready
9. Transcoding
تخيل المدرس رفع:
4K
مش كل الطلاب عندهم اتصال يسمح بـ 4K.
فالنظام ممكن ينتج عدة renditions:
360p
480p
720p
1080p
1440p
2160p
مع bitrates مختلفة.
مثلاً:
360p → 800 Kbps
480p → 1.5 Mbps
720p → 3 Mbps
1080p → 6 Mbps
الأرقام مجرد مثال، وليست قاعدة ثابتة.
الاختيار الحقيقي يعتمد على:
- Resolution
- Codec
- Frame rate
- Content type
- Target devices
- Bandwidth
- Cost
- Quality requirements
AWS MediaConvert، مثلًا، يدعم مجموعات مخرجات ABR مثل HLS وDASH وCMAF. citeturn1search3turn1search5
10. Adaptive Bitrate Streaming
هنا تبدأ القوة الحقيقية.
بدل ما يكون عندك:
video.mp4
واحد فقط.
عندك مجموعة من النسخ:
1080p
720p
480p
360p
والـ player يختار بينها حسب ظروف الشبكة والجهاز.
مثلاً:
Fast Internet
↓
1080p
Internet gets worse
↓
720p
Internet gets worse
↓
480p
وبالتالي المستخدم لا يحتاج بالضرورة أن يوقف الفيديو ويختار الجودة يدويًا.
Apple توضح أن HLS يدعم عدة streams بمعدلات مختلفة والتبديل بينها حسب ظروف الشبكة. citeturn1search4
11. HLS و DASH
من أشهر طرق تقديم الفيديو:
HLS
DASH
بدل إرسال ملف فيديو ضخم كقطعة واحدة، يتم تجهيز الفيديو كـ segments مع manifest يصف الـ streams المتاحة.
مثلاً HLS:
master.m3u8
ثم:
720p/
segment001.m4s
segment002.m4s
segment003.m4s
1080p/
segment001.m4s
segment002.m4s
segment003.m4s
والـ player يقرر أي rendition يستخدم.
HLS مصمم ليعمل عبر HTTP وCDNs، ويدعم VOD وlive streaming والتكيف مع ظروف الشبكة. citeturn1search4turn1search15
12. Video Deduplication
تخيل:
Teacher A
رفع فيديو.
وبعده:
Teacher B
رفع نفس الملف بالضبط.
هل لازم تخزن:
2 × 2GB
؟
مش دائمًا.
ممكن تستخدم:
Content Hash
مثلاً:
SHA-256(video)
وتخزن:
hash → object
لو نفس الـ hash موجود:
Don't upload/store another copy
وتعمل reference للـ asset الموجود.
لكن خلي بالك:
الـ hash وحده مش كفاية كسياسة business.
لأن عندك أسئلة ownership وpermissions وretention.
13. Processing Pipeline
بعد الرفع، الأفضل غالبًا ألا تجعل الـ API نفسها تنتظر:
Transcoding
Thumbnail
Captions
...
بدل ذلك:
Upload Completed
↓
Event / Queue
↓
Worker
↓
Processing
مثلاً:
VideoUploaded
↓
Queue
↓
Transcoding Worker
↓
Packaging Worker
↓
Thumbnail Worker
↓
Metadata Update
↓
Video Ready
وده يسمح لك تعمل:
- Retries
- Concurrency control
- Monitoring
- Backpressure
- Horizontal scaling
- Failure isolation
14. Webhooks
إزاي تعرف إن الـ processing خلص؟
مش لازم تفضل تعمل:
GET /video/status
كل 5 ثواني:
خلصت؟
خلصت؟
خلصت؟
خلصت؟
لو الـ provider يدعم Webhooks، ممكن يقولك:
POST /api/videos/webhook
مثلاً:
{
"event": "video.ready",
"videoId": "vid_123"
}
أو:
{
"event": "video.failed",
"videoId": "vid_123"
}
لكن مهم:
Webhooks ليست ضمانًا سحريًا.
لازم تتعامل مع:
- Signature verification
- Duplicate events
- Retries
- Out-of-order events
- Idempotent handlers
والـ polling ممكن يفضل مفيد كـ fallback أو reconciliation mechanism حسب الـ provider.
15. CDN
تخيل عندك:
Student Egypt
Student Germany
Student Saudi Arabia
Student USA
هل كلهم لازم يجيبوا الفيديو من نفس الـ origin؟
لو عملت:
User
↓
Origin Server
على scale كبير هتواجه:
- Latency
- Bandwidth pressure
- Origin overload
- Higher cost
عشان كده:
User
↓
Nearest CDN Edge
↓
Cache
↓
Origin only when needed
الـ CDN يوزع الـ video segments عالميًا.
وده يقلل الضغط على الـ origin ويقرب المحتوى من المستخدم.
16. حماية الفيديو المدفوع
دلوقتي عندك كورس مدفوع.
هل ينفع:
/video/course1/lesson1.mp4
يبقى public؟
❌ غالبًا لا.
لأن أي شخص يحصل على الرابط ممكن يشاركه.
الحل يكون حسب مستوى الحماية المطلوب:
Authentication
+
Authorization
+
Signed URLs / Tokens
+
Short Expiration
+
CDN access controls
+
Encryption
+
DRM (للـ premium/high-value content)
17. Signed URLs و Playback Tokens
بدل ما الـ Frontend ياخد رابط دائم:
https://cdn.example.com/video.mp4
ممكن يطلب:
POST /videos/vid_123/playback
الـ Backend يتحقق:
User authenticated?
↓
Purchased course?
↓
Enrollment active?
↓
Video belongs to course?
↓
Generate short-lived access
ويرجع:
{
"playbackUrl": "https://cdn.example.com/...",
"expiresAt": "..."
}
أو token تستخدمه الـ player/provider.
Amazon S3 Presigned URLs مثال على URLs محدودة الصلاحية تسمح بالوصول أو الرفع وفق الصلاحيات التي حددها منشئ الرابط. citeturn0search7
18. DRM
لو المحتوى عالي القيمة، ممكن تحتاج:
Digital Rights Management
أمثلة:
Widevine
PlayReady
FairPlay
الفكرة مش مجرد:
Hide the URL
بل المحتوى نفسه يمكن أن يكون encrypted، والـ player يستخدم نظام حماية مناسب للحصول على license/key وفق قواعد الوصول.
W3C Encrypted Media Extensions توفر API للتعامل مع المحتوى المشفر وأنظمة الـ key/license، لكنها لا تعرّف DRM system واحدًا بنفسها. citeturn1search1
Google Widevine هو نظام حماية للمحتوى premium ويعتمد على EME وCommon Encryption، ويستخدمه عدد من خدمات البث الكبرى. citeturn1search0
19. هل DRM يمنع تسجيل الشاشة؟
هنا لازم نفهم الحقيقة:
❌ لا توجد حماية 100%
DRM يرفع مستوى الحماية جدًا، لكنه لا يجعل المحتوى مستحيل النسخ.
لأن في النهاية:
Human
↓
Screen
ممكن يتم تصويرها بطرق مختلفة.
لكن DRM يصعّب جدًا الحصول على المحتوى الخام أو تشغيل الملفات المشفرة خارج البيئة المصرح بها.
⚠️ ملاحظة مهمة عن Widevine L1/L3
من الأخطاء الشائعة في مقالات System Design إننا نقول:
"أي منصة كبيرة لازم L1"
الصحيح إن مستويات الحماية تختلف حسب الجهاز، الـ DRM implementation، ومتطلبات المحتوى والمنصة.
وWidevine نفسه يدعم تكاملات على أجهزة ومنصات مختلفة، لكن تفاصيل الـ security level والقدرات المتاحة تعتمد على الجهاز والـ implementation.
ففي الانترفيو الأفضل تقول:
"For premium content, I would evaluate DRM such as Widevine, PlayReady, or FairPlay based on target devices and security requirements."
بدل ما تفترض أن كل منصة تستخدم نفس المستوى على كل جهاز.
20. Scale و Cost Optimization
تخيل:
100,000 videos
و:
Millions of views/day
هنا تبدأ أسئلة جديدة.
Storage
هل كل الفيديوهات لازم تكون في Hot Storage؟
لا.
ممكن تعمل Lifecycle Policies:
Hot
↓
Cool / Infrequent Access
↓
Archive
حسب طبيعة الاستخدام.
Amazon S3 Lifecycle يدعم انتقال objects بين storage classes وأرشفتها أو حذفها وفق قواعد محددة. citeturn0search2turn0search3
Processing Cost
مش لازم كل فيديو يتعمله:
4K
1440p
1080p
720p
480p
360p
لو جمهورك أصلًا لا يحتاج كل ده.
الـ encoding ladder قرار:
Business
+
Quality
+
Devices
+
Bandwidth
+
Cost
21. Queues
تخيل:
10,000 videos
كلهم اترفعوا في نفس الوقت.
هل تشغل 10,000 transcoding jobs مرة واحدة؟
❌ غالبًا لا.
تستخدم Queue:
Uploaded
↓
Queue
↓
Workers
↓
Transcoding
أمثلة:
RabbitMQ
Kafka
AWS SQS
Azure Service Bus
والاختيار يعتمد على نوع الـ workload.
المهم إنك تعمل:
Backpressure
Retry
Concurrency limits
Dead-letter handling
Monitoring
22. Observability
لو فيديو واحد processing فشل.
هل هتعرف؟
لو الـ transcoding latency زاد 300%.
هل هتعرف؟
لو CDN cache hit ratio وقع.
هل هتعرف؟
لو upload failures زادت.
هل هتعرف؟
لازم تراقب:
Upload success rate
Upload duration
Processing duration
Transcoding failures
Queue depth
Worker utilization
CDN cache hit ratio
Playback failures
Buffering / rebuffering
Startup time
Error rate
Storage usage
Bandwidth
Cost
وتربط الـ metrics بالـ logs والـ traces.
23. Architecture كاملة
الصورة الكبيرة ممكن تبقى:
┌──────────────────┐
│ Teacher │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Frontend │
└────────┬─────────┘
│
Create Upload Session
│
▼
┌──────────────────┐
│ Backend │
│ Auth / Quota │
│ Authorization │
└────────┬─────────┘
│
Signed Upload URL
│
▼
┌────────────────────────┐
│ Object Storage │
│ Raw Video │
└────────────┬───────────┘
│
Upload Completed
│
▼
┌──────────────────┐
│ Queue / Events │
└────────┬─────────┘
│
▼
┌────────────────────────┐
│ Video Processing │
│ │
│ Validation │
│ Metadata │
│ Transcoding │
│ Thumbnails │
│ Captions │
│ Packaging │
│ Encryption │
└────────────┬───────────┘
│
▼
┌────────────────────────┐
│ Streaming Storage │
│ HLS / DASH / CMAF │
└────────────┬───────────┘
│
▼
┌─────────────┐
│ CDN │
└──────┬──────┘
│
▼
┌──────────────────┐
│ Student │
│ Player │
└──────────────────┘
24. سيناريو عملي
خلينا نمشي من أول زرار Upload:
Step 1 — المدرس يختار الفيديو
video.mp4
20 GB
Step 2 — Frontend يطلب Upload Session
POST /api/videos/upload-session
Step 3 — Backend يتحقق
Authenticated? ✅
Teacher? ✅
Owns course? ✅
Quota available? ✅
Size allowed? ✅
Step 4 — Backend ينشئ upload URL
{
"videoId": "vid_123",
"uploadUrl": "...",
"expiresAt": "..."
}
Step 5 — Frontend يرفع مباشرة
Frontend
↓
Storage
وليس:
Frontend
↓
Backend
↓
Storage
Step 6 — Resumable Upload
20 GB
↓
chunks
↓
upload
لو حصل failure:
resume
Step 7 — Upload Completed
video.status = PROCESSING
Step 8 — Queue
VideoUploaded
↓
Queue
Step 9 — Processing
Validate
↓
Extract metadata
↓
Transcode
↓
Generate thumbnails
↓
Generate captions
↓
Package HLS/DASH
Step 10 — Provider/Event
video.ready
Step 11 — Backend updates database
status = READY
Step 12 — Student opens lesson
GET /api/videos/vid_123/playback
Step 13 — Authorization
Logged in? ✅
Bought course? ✅
Enrollment? ✅
Step 14 — Playback access
Short-lived token / signed access
Step 15 — Player
Manifest
↓
CDN
↓
Segments
↓
Adaptive bitrate
↓
Playback
25. أسئلة الانترفيو الحقيقية
السؤال مش:
"إزاي أرفع فيديو؟"
السؤال الحقيقي:
Upload
- الفيديو هيتخزن فين؟
- هل الـ Backend يستقبل الملف؟
- ليه Direct Upload أفضل؟
- إزاي تتعامل مع 20GB؟
- إيه اللي يحصل لو النت فصل عند 95%؟
- هل تحتاج Resumable Upload؟
- هل تستخدم TUS ولا Multipart Upload؟
Security
- مين مسموح له يرفع؟
- إزاي تمنع user من استنزاف الـ storage؟
- إزاي تمنع upload لأي file؟
- إزاي تحدد size؟
- إزاي تمنع abuse؟
- هل Upload URL دائم؟
Processing
- مين يعمل Transcoding؟
- هل الـ HTTP request يستنى؟
- إزاي تعمل retries؟
- إيه اللي يحصل لو worker مات؟
- إزاي تعرف إن processing خلص؟
Streaming
- ليه MP4 واحد مش كفاية؟
- إيه HLS؟
- إيه DASH؟
- إيه Adaptive Bitrate؟
- إيه Manifest؟
- إيه Segment؟
Scale
- ماذا يحدث عند مليون مشاهدة؟
- كيف تستخدم CDN؟
- ماذا يحدث للـ origin؟
- كيف تقلل bandwidth؟
- كيف تتعامل مع queue backlog؟
Security of playback
- هل الـ video URL public؟
- إزاي تمنع مشاركة الرابط؟
- إيه Signed URL؟
- إيه Playback Token؟
- هل تحتاج DRM؟
- ما الفرق بين encryption وDRM؟
Cost
- هل كل الفيديوهات في Hot Storage؟
- هل نعمل lifecycle؟
- هل نعمل deduplication؟
- هل نعمل كل resolutions لكل فيديو؟
🧠 أهم Trade-offs
| Decision | Advantage | Trade-off |
|---|---|---|
| Backend Upload | أبسط | Bandwidth + scalability |
| Direct Upload | scalable | يحتاج signed upload flow |
| Resumable Upload | يتحمل network failures | implementation أعقد |
| Object Storage | scalable | يحتاج access strategy |
| Video Platform | processing/streaming جاهز | vendor dependency + cost |
| Self-hosted transcoding | تحكم أكبر | infrastructure معقد |
| HLS/DASH | adaptive streaming | pipeline أعقد |
| CDN | أداء عالمي | cost + cache strategy |
| Signed URLs | حماية أفضل | token management |
| DRM | حماية قوية للمحتوى | complexity + licensing |
| Deduplication | يقلل storage | hashing + ownership logic |
| Queue | resilience + scale | eventual consistency |
⚠️ أخطاء شائعة
❌ Error 1
POST /upload
والـ Backend يستقبل 20GB.
❌ Error 2
تخزين الفيديو داخل:
/uploads
على Application Server.
❌ Error 3
إرجاع:
/video.mp4
كرابط public دائم.
❌ Error 4
عمل Transcoding داخل HTTP request.
❌ Error 5
عدم وجود Resumable Upload.
❌ Error 6
تشغيل transcoding لكل الملفات بدون Queue أو concurrency control.
❌ Error 7
الاعتماد على polling فقط لمعرفة حالة processing.
❌ Error 8
عدم التحقق من Webhook signature.
❌ Error 9
الاعتقاد أن:
Signed URL = DRM
هما ليسا نفس الشيء.
❌ Error 10
الاعتقاد أن:
DRM = impossible to copy
لا توجد حماية مطلقة من capture.
🎯 الإجابة المثالية في الانترفيو
لو interviewer سألك:
"Design a video upload and streaming system for an educational platform."
ممكن تبدأ:
"I wouldn't treat this as a simple file upload. I would separate upload, processing, storage, and playback delivery."
ثم:
1. Direct upload to object storage/video platform
2. Signed / one-time upload authorization
3. Resumable upload for large or unreliable uploads
4. Store metadata in DB
5. Publish processing job/event
6. Async transcoding pipeline
7. Generate multiple bitrate renditions
8. Package as HLS/DASH
9. Store processed assets
10. Deliver through CDN
11. Protect playback with authorization + signed access
12. Use DRM when content value requires it
13. Webhooks + idempotent processing state
14. Queues + retries + DLQ
15. Observability + cost controls
وبعدها تبدأ تسأل interviewer:
Is this VOD or live streaming?
What is the maximum video size?
How many uploads per day?
How many concurrent viewers?
Do we need DRM?
Which countries/devices do we support?
What are the latency requirements?
What is the acceptable processing time?
How much can we spend per GB?
Do users need downloads/offline playback?
وده مهم جدًا.
لأن الـ System Design القوي مش إنك تحفظ architecture.
هو إنك تعرف:
إيه الأسئلة اللي لازم تتسأل قبل ما تختار architecture.
🏁 الخلاصة
رفع الفيديو مش:
Receive File
↓
Save File
↓
Return URL
في منصة تعليمية كبيرة، أقرب إلى:
Upload
↓
Authorization
↓
Direct / Resumable Upload
↓
Object Storage
↓
Queue
↓
Validation
↓
Transcoding
↓
Multiple Bitrates
↓
HLS / DASH
↓
Encryption / DRM if needed
↓
CDN
↓
Playback Authorization
↓
Student
وفي الخلفية:
Retries
Queues
Webhooks
Idempotency
Monitoring
Analytics
Caching
Cost Optimization
Lifecycle Policies
Security
والسؤال الحقيقي في الانترفيو مش:
"إزاي أخلي الفيديو يترفع؟"
لكن:
"إزاي أبني نظام يقدر يستقبل فيديوهات ضخمة، يعالجها، يحميها، ويوصلها لملايين المشاهدين بدون ما الـ system ينهار؟"
وده الفرق بين:
File Upload
و:
Video Platform Engineering
📚 مصادر رسمية
-
AWS S3 Presigned Uploads:
https://docs.aws.amazon.com/AmazonS3/latest/userguide/PresignedUrlUploadObject.html -
AWS S3 Lifecycle:
https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-configuration-examples.html -
Cloudflare Stream Direct Creator Uploads:
https://developers.cloudflare.com/stream/uploading-videos/direct-creator-uploads/ -
Cloudflare Stream Resumable Uploads / TUS:
https://developers.cloudflare.com/stream/uploading-videos/resumable-uploads/ -
Apple HTTP Live Streaming:
https://developer.apple.com/documentation/http-live-streaming -
AWS MediaConvert ABR Output Groups:
https://docs.aws.amazon.com/mediaconvert/latest/ug/choosing-your-streaming-output-groups.html -
W3C Encrypted Media Extensions:
https://www.w3.org/TR/encrypted-media/ -
Google Widevine:
https://developers.google.com/widevine/drm/overview -
MDN HTTP Range Requests:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Range_requests
<div align="center">
🚀 The real interview question
Don't design an upload endpoint.
Design a system that survives scale.
Upload → Process → Protect → Stream → Observe → Scale
</div>منشورات مقترحة
مشاريع ذات صلة
منصة تعليمية تتيح تصفح الكورسات، وتشغيل الفيديو المحمي عبر روابط Cloudinary الموقعة، وتتبع تقدم الطلاب، والدفع عبر PayPal.