Netflix 的系统设计面完了，难度确实不低。整理了面试里碰到的真题和思路，以及面完之后的反思，给正在备战 Netflix SDE NG System Design 的同学参考。
Netflix 系统设计的特点是：题目不偏门，基本都是”设计 Netflix 本身的某个子系统”，但追问会往 Open Connect、离线/在线架构分离、cold start 这些方向深挖，通用的 SD 套路不够用。
真题一：从零构建视频流媒体平台
题目：如果让你 design 一个 video streaming platform，你会从哪些 components 入手？
这是最基础也是最高频的一道，但覆盖范围很广，面试官会根据你的回答决定往哪个方向深挖。
核心架构
微服务是这道题的标准选型，把认证、内容管理、推荐、计费、播放拆成独立服务，独立部署和扩展，故障隔离。不需要论证选微服务还是单体，直接说微服务并解释每个服务的职责划分。
视频的生命周期
视频从上传到用户看到分三段：
第一段是 Ingestion——用户上传原始视频文件，存入原始存储（S3 或 GCS），同时触发转码任务队列。
第二段是 Transcoding——将原始视频转成多种分辨率（4K/1080p/720p/480p）和多种格式（H.264/H.265/VP9/AV1），生成不同码率的版本支持自适应比特率（ABR）播放。转码是计算密集型任务，通常用 GPU 集群并行处理，并通过消息队列（Kafka）异步调度。
第三段是分发——转码完成的视频文件存入 CDN，用户播放时从最近的 CDN 节点拉取。
CDN 的关键作用
Netflix 自建了 Open Connect CDN（OCA）——把硬件服务器直接部署到 ISP 内部，用户请求不用跨出运营商网络，从根本上解决延迟问题。深夜低峰期把热门内容预加载到本地 OCA 服务器，白天用户请求直接命中本地缓存。
面试官通常会在这里追问：如何预测哪些内容要预加载（历史播放数据 + 机器学习预测）、OCA 节点挂了怎么回源（多级回源策略）。
scalability 和 fault tolerance
全球 200M+ 用户同时在线，关键设计点：
数据库层用 Cassandra（宽列存储，写多读多场景表现好）；用户会话管理用 Redis；视频元数据（标题、描述、分类）用 MySQL 加读写分离；每个服务独立扩容；用 Circuit Breaker（如 Hystrix）防止级联故障。
peak traffic 处理：热门剧集首播时流量可能瞬时暴增——auto-scaling 提前预热（pre-warming）、流量整形（traffic shaping）限制单用户带宽、graceful degradation 在极端情况下降低视频质量保证可用性。
真题二：推荐系统设计
题目：design Netflix 的 recommendation system，你会考虑哪些 factors？
数据基础
推荐的起点是数据。显式数据（用户评分、点赞）只是一部分，更重要的是隐式行为：观看时长（看了 80% vs 看了 10% 就退出）、搜索历史、暂停位置、完播率、重播次数。
算法选择
协同过滤（Collaborative Filtering）：基于”和你行为相似的用户也喜欢 X”，对头部内容效果好，但有冷启动问题。
基于内容的推荐（Content-based Filtering）：基于”你看过 A，A 和 B 类似”，依赖内容标签，冷启动友好，但容易陷入”信息茧房”。
深度学习：用用户历史序列（LSTM/Transformer）做更复杂的模式提取，Netflix 内部有 Wide & Deep、Two-Tower 等模型。
实际系统用混合模型：先用协同过滤召回候选集，再用深度模型做精排。
Cold Start 问题
这是面试官必问的追问。新用户没有行为数据怎么推荐：
新用户注册时让选喜好类型（genre selection）；前几次用全球热门内容或地区热门填充；用人口统计特征（年龄、地区）做基础推荐；快速累积几次行为后切换到个性化模型。
离线 + 在线架构
离线：定期（每天或每小时）用全量数据训练模型，生成用户-内容的相关性矩阵，存入 Key-Value 存储（Redis / DynamoDB）。
在线：用户打开 App 时，实时读取预计算好的推荐结果，结合当前上下文（时间、设备、当前观看位置）做轻量级实时调整。
离线保证精度，在线保证低延迟，不能只做其中一个。
A/B Testing
推荐系统的改进全靠 A/B Testing。不同用户群看到不同的推荐算法，对比完播率、点击率、留存率等指标，由数据决定哪个版本上线。
真题三：视频编码 Pipeline 设计
题目：implement Netflix 的 video encoding pipeline，你会包含哪些 stages？
这道题考的是对媒体工程流程的熟悉度。
完整 Pipeline
视频 Ingestion → 视频拆段（Segmentation）→ 并行转码（Parallel Transcoding）→ 质量优化（Quality Optimization）→ 缩略图生成（Thumbnail Generation）→ 打包（Packaging）→ 推送 CDN。
关键设计点
转码是 CPU/GPU 密集型，要并行化。Netflix 的做法是把视频切成小片段（chunk），每个 chunk 独立转码，最后合并——这样一部 2 小时的电影可以在几十台机器上同时处理，把转码时间从小时级压缩到分钟级。
格式支持：H.264（兼容性最好）、H.265（同画质更小文件）、AV1（Netflix 主推，压缩效率最高，但编码慢）。
自适应比特率（ABR）：同一视频输出多个码率版本，播放器根据当前网络状况动态切换，保证流畅播放。
缩略图生成：每隔几秒取一帧，生成缩略图用于拖动进度条时的预览，这个往往被忽略但是面试官会问。
面完的几点反思
反思一：CDN 要讲 Open Connect，不能只说”用 CDN”
Netflix 自建 CDN 是他们最核心的技术差异，面试官期待你知道这个。说”用 Cloudflare”或者”用 CDN 分发”是不够的，要讲 OCA 部署到 ISP 内部这个关键决策和它的原因。
反思二：推荐系统的 cold start 一定要主动讲
这是面试官对推荐系统追问的必考点，等他问了再回答不如提前说出来——主动覆盖说明你真的做过思考，而不是被追问才想到。
反思三：离线/在线架构分离是 Netflix 体系的核心思路
这个思路不只用在推荐系统，内容分发（预加载 vs 实时拉取）、计费（批量结算 vs 实时扣费）都有类似的设计权衡，理解了这个思路才能答好追问。
反思四：peak traffic 的应对要说具体策略
说”用 auto-scaling”不够，要说 pre-warming（提前几小时把实例数扩上去，避免冷启动延迟）、traffic shaping（限制单连接带宽防止少数用户占满资源）、graceful degradation（降低视频质量而不是拒绝服务）。
需要完整版面经和更多 Netflix 系统设计真题，或者想针对性准备系统设计面试，可以来找我们。我们是 InterviewShow，做过 Netflix、Meta、Google 这些公司的面试，Netflix 的 Open Connect、推荐系统离线/在线架构、视频编码 Pipeline 这几块都有专门的准备方案，一对一跟着走，有需要的来聊。