Nền tảng video

1) Người dùng có thể tải lên video lớn và tiếp tục khi mất mạng

File gốc vài trăm MB đến vài GB không nên đi qua API server. API chỉ cấp presigned URL, client chia file thành phần 8 MB và đẩy thẳng lên object storage bằng multipart upload.

1. 1Client gọi POST /v1/uploads với kích thước file, nhận uploadId và URL cho từng phần
2. 2Client PUT song song 3-4 phần một lúc lên S3/GCS, phần lỗi thì gửi lại riêng phần đó
3. 3Mất mạng: client gọi GET /v1/uploads/{id} để biết phần nào đã có và gửi tiếp
4. 4Xong hết thì gọi /complete, storage ghép thành một object raw/{videoId}

Nguồn: Grokking Modern System Design · ch.26 Design YouTube ↗ · bài "Design of YouTube" · mục "High-level design" (upload, blob storage) ; Grokking Modern System Design · ch.20 Blob Store ↗ · bài "Design of a Blob Store" · mục "Write a blob" (chia blob thành chunk) ; Chưa có nguồn trong thư viện: presigned URL và multipart upload của S3/GCS không có trong sách

2) Hệ thống xử lý video thành nhiều độ phân giải

Sự kiện upload xong kích hoạt một DAG job: kiểm tra file, cắt thành đoạn, encode song song từng đoạn ở từng mức, rồi đóng gói thành HLS/DASH. Mỗi job idempotent nên chạy lại được khi worker chết.

1. 1Object storage phát sự kiện upload xong vào queue
2. 2Orchestrator tạo DAG: probe → split → encode (đoạn × mức) → package → thumbnail
3. 3Worker ffmpeg lấy job, encode đoạn 10 s ở một mức, ghi kết quả lên storage
4. 4Đủ đoạn thì package sinh manifest .m3u8/.mpd, cập nhật Video sang READY

Nguồn: Grokking Modern System Design · ch.26 Design YouTube ↗ · bài "Design of YouTube" · mục "High-level design" (encoder/transcoder tạo nhiều độ phân giải) ; Grokking Modern System Design · ch.26 Design YouTube ↗ · bài "The Reality Is More Complicated" · mục "Encode" (chia video thành segment, encode từng segment) ; Grokking Modern System Design · ch.23 Distributed Task Scheduler ↗ · mục "Task idempotency" ; Chưa có nguồn trong thư viện: định dạng HLS/DASH và ffmpeg

3) Người dùng có thể xem video mượt theo tốc độ mạng

Video được lưu thành các segment 4 s ở nhiều bitrate. Player tải manifest, đo băng thông và độ đầy buffer, tự chọn mức phù hợp cho từng segment. Mọi segment đi qua CDN vì nội dung không bao giờ đổi.

1. 1Client gọi GET /v1/videos/{id}, nhận URL master manifest có chữ ký hết hạn
2. 2Player tải master manifest từ CDN, chọn mức khởi đầu thấp để phát nhanh
3. 3Player tải segment tiếp theo, tăng hoặc giảm mức theo băng thông đo được
4. 4CDN miss thì lấy từ origin shield, rồi mới tới object storage

Nguồn: Grokking Modern System Design · ch.26 Design YouTube ↗ · bài "The Reality Is More Complicated" · mục "Adaptive streaming" (chọn chunk theo băng thông và buffer), mục "Deliver" ; Grokking Modern System Design · ch.11 Content Delivery Network (CDN) ↗ · mục "Multi-tier CDN architecture" ; Chưa có nguồn trong thư viện: độ dài segment 4 s và URL ký hết hạn

4) Người dùng có thể xem thông tin video và số lượt xem

Metadata đọc nhiều hơn ghi rất nhiều nên đi qua cache. Lượt xem được ghi thành sự kiện và cộng dồn bất đồng bộ, số hiển thị có thể trễ vài phút.

1. 1API đọc metadata từ Redis, miss thì đọc DB replica rồi ghi lại cache
2. 2Player gửi heartbeat /views mỗi 30 s
3. 3Heartbeat vào bộ đếm (Redis ở mức vừa, Kafka + stream job ở mức lớn)
4. 4Bộ đếm định kỳ ghi tổng vào DB, cache metadata được làm mới

Nguồn: Grokking Modern System Design · ch.26 Design YouTube ↗ · bài "Evaluation of YouTube's Design" · mục "Distributed cache", "Consistency" (chấp nhận nhất quán yếu cho số liệu không quan trọng) ; Grokking Modern System Design · ch.16 Distributed Cache ↗ · mục "Writing policies" ; Grokking Modern System Design · ch.24 Sharded Counters ↗ · mục "High-level solution sketch"

1) Upload file 2 GB qua mạng di động chập chờn thế nào để không phải làm lại từ đầu?

2) Pipeline transcode được tổ chức thế nào để video 1 giờ không phải chờ 1 giờ?

3) Phát video mượt cho người xem ở mạng 3G lẫn cáp quang, với chi phí băng thông chấp nhận được?

4) Đếm lượt xem cho hàng trăm triệu lượt mỗi ngày, và dùng dữ liệu đó để giảm chi phí lưu trữ thế nào?