系统设计 Lab
视频平台其实是两个系统：ingest 端是计算密集的 transcode pipeline，playback 端是读极重的 CDN。
调整每天上传量、平均视频时长、并发观众、catalog 大小、每个视频编码多少个 bitrate rendition、峰值倍数，以及 region 数。设计会从一台直接服务文件的单机，演进到 CDN offload、queue 加 transcode worker farm、sharded object storage 配独立 metadata store，最后到 multi-region multi-CDN 分发。
分步讲解
一步一步把它想清楚
要点
常规演进场景
从左到右点击，就是预设的演示路径。每张卡片都会改变 workload 输入。
推荐形态
当前架构路径
Clients
Viewer 请求 manifest 并流式拉取视频 segment，随带宽变化切换 bitrate
Uploader 提交一个新源视频去 transcode 并发布
Edge / CDN
CDN 在 edge 缓存视频 segment，让 origin 省下绝大部分 playback egress
Multi-CDN 把分发铺到多个 region 和厂商，换取容量和低启动延迟
Upload + API
Upload + API 接收上传、服务 manifest，并为 playback 解析 metadata
Packager 把 rendition 切片并打包成 adaptive manifest 供 player 用
Transcode
Job queue 缓冲 transcode job，让 ingest 峰值永远不会阻塞上传或 playback
Worker farm 把一个源视频并行 fan-out 成每一个 bitrate rendition
Live encoder 实时 transcode 直播 ingest，没有重新编码的机会
Storage
Object store 作为 playback origin，持久存放源视频和每一个编码出的 rendition
Metadata DB 存放标题、manifest，以及 playback 要查的每个视频的 metadata
瓶颈
CDN offload / origin egress
Transcode 积压
Object storage 大小
Metadata QPS
全球分发延迟
为什么会变
决策权衡
有出处支撑的规则
这些是模型背后那些经得起时间考验的 system design 论断。而 slider 的具体阈值，则被刻意标注为教学用的假设。
流媒体视频从 CDN cache 分发，而不是 origin
CDN 在靠近观众的 edge 节点缓存 segment；origin 只服务 cache miss，这是 playback egress 唯一能扩展的方式。
AWS CloudFrontAdaptive bitrate streaming 打包多个 rendition 供 player 切换
HLS（和 DASH）用一份切好片的 rendition media playlist，让 player 挑一个适配当前带宽的 bitrate；这正是 ingest 必须编码好几档 profile 的原因。
Apple HTTP Live StreamingTranscoding 作为异步 job 跑在由 queue 喂料的 worker farm 上
基于文件的 transcoding 以 job 形式提交，由弹性 worker 处理，于是上传峰值排队而不是阻塞请求路径。
AWS Elemental MediaConvertObject storage 是媒体文件持久、可扩展的 origin
源视频和每一个 rendition 都放在 object storage 里，它的存储和持久性独立于计算和服务层扩展。
Amazon S3教学用假设
- Playback 带宽按 concurrentViewers x 峰值倍数 x ~5 Mbps 建模；CDN offload 假设热门内容在 edge 缓存命中率高。
- Transcode 计算量近似为 profile 数 x 源分钟数 x 每 worker 的固定系数；真实 encoder 随 codec 和分辨率而变。
- Storage 算上每个视频的源加 rendition；单节点的 QPS、egress 和存储预算都是保守的教学数字，不是厂商上限。