一句话总结

Dream11的系统设计面试不是在考你能写多少代码，而是要判断你能否在高并发、海量用户和实时赛事数据的场景下，搭建一个既可靠又可演进的产品架构。正确的判断是：聚焦业务核心指标、用可拆解的模块化思路、在有限时间内展示权衡取舍的逻辑；而不是盲目罗列技术栈、堆砌图表、或者仅凭直觉给出理想化方案。

适合谁看

本篇面向的读者是：

  1. 已经有2年以上互联网产品经理经验，准备转向或已在Dream11类似的体育竞猜平台工作的候选人。
  2. 正在准备2026年Dream11 PM系统设计轮的求职者，尤其是对分布式系统、流式计算和实时推荐有基本认知的人。
  3. 对面试官评判标准想要透彻了解，以便在现场能够“用对话的方式”把思考过程写在白板上的人。

如果你是应届毕业生、只做过单体APP的PM，或者对后端技术一窍不通，请先完成基础的系统设计入门课程再回来看这篇。

核心内容

Dream11系统设计面试全流程拆解

Dream11的PM面试分为四轮，分别是：

  1. 简历筛选（30秒）——系统会自动抓取你在简历里提到的“实时数据处理”“千万人同时在线”等关键字。
  2. 第一次深度轮（45分钟）——由资深PM主导，围绕“如何设计一个支持每日10万场比赛实时比分推送的系统”。考察点包括业务拆解、关键指标、容量估算。
  3. 系统设计白板（60分钟）——由后台架构师和资深PM共同评审。重点在于模块划分、数据流向、容错方案以及成本控制。
  4. 文化匹配+薪资谈判（30分钟）——HR会把薪资结构拆成Base、RSU、Bonus三项，分别给出数字。

不是只看你能说出Kafka和Redis的组合，而是看你能否解释为什么在峰值5秒内必须把比分推送到99%活跃用户手中。在第一次深度轮中，面试官会给出一个具体的业务场景：假设今天有一场IPL决赛，预计同时在线用户峰值为180万。候选人需要在5分钟内给出容量估算（如每秒写入2000条比分事件、每秒读取30万次），并说明如何使用分区、限流和缓存层来保证SLA。

Insider场景：debrief会议的真实对话

在2025年9月的一次内部debrief中，Hiring Committee的Tech Lead对上一次面试的表现做了如下点评：

> Tech Lead：“候选人在数据分区上说‘把所有赛事按日期分库’是典型的不是把问题抽象到业务维度，而是停留在数据库层面的思路。我们更期待他把‘赛事’拆成‘比赛状态流’、‘用户订阅流’两条独立的Kafka Topic，并说明为什么这样可以降低耦合。”

> PM Manager：“他在容量估算时只给出‘大概几百GB’，没有提供具体的QPS和峰值压缩率。我们要的不是‘大概’，而是不是随意估算，而是基于历史数据给出可量化的数字。”

从这段对话可以看到，面试官真正关心的是思考路径的透明度和可验证性，而不是最终答案的完美度。

Insider场景：Hiring Committee的最终决策讨论

在一次Hiring Committee的final decision里，HR与两位PM围绕候选人的表现展开争论：

> HR：“他的期望薪资是Base $180K，RSU $150K/年，Bonus $30K。市场上同级别的PM一般Base在$150K-$200K之间，RSU在$100K-$200K。我们可以接受。”

> PM Lead：“他在系统设计中没有体现对成本的敏感度。我们在真实项目里，单纯加一层缓存会把成本提升30%。如果他不能在设计里主动提出‘成本‑效益分析’，我担心后期会频繁出现预算超支。”

> HR：“不是因为他缺少成本意识而直接淘汰，而是要在后续的culture fit面谈里进一步验证。”

这段对话提醒候选人，不是只展示技术方案，而是要在方案里自然嵌入成本、可运维性和业务价值的权衡。

真题解析：从“实时比分推送”到“全局推荐系统”

  1. 业务拆解：先明确核心指标——推送时效（<5秒）、覆盖率（>99%活跃用户）和成本（每月云资源不超过$30K）。
  2. 模块划分：
    • 数据采集层：使用Kafka Connect从赛事提供商拉取原始比分。
    • 处理层：Flink实时计算，生成每场比赛的状态流。
    • 缓存层：Redis Cluster做热点比分缓存，TTL设置为30秒。
    • 推送层：通过WebSocket + CDN边缘节点下发。
    • 容量估算：假设峰值每秒产生2000条比分事件，Flink每秒处理2M记录，Redis需要支撑30万QPS的读取。根据AWS的实例规格，计算出需要的节点数和费用。
    • 容错方案：Kafka使用副本数3，Flink开启checkpoint，每分钟一次。Redis采用主从复制加Sentinel。
    • 成本权衡：如果把Redis换成Memcached，成本下降约15%，但缺少持久化导致数据回滚风险增加。

不是只给出‘使用Kafka+Flink+Redis’，而是要解释每一步的选型原因、容量计算以及备份策略，这样才能在面试中获得“结构完整、思考深度”加分。

准备清单

  1. 梳理自己过去负责的高并发或实时系统项目，准备3个能量化的指标（如峰值QPS、延迟、成本）。
  2. 熟悉Dream11的核心业务流程：赛事报名、实时比分、即时竞猜、用户奖励。把每一步映射成系统模块。
  3. 系统性拆解面试结构（PM面试手册里有完整的系统设计实战复盘可以参考），尤其要练习在15分钟内完成业务拆解、容量估算和模块划分。
  4. 练习在白板上快速画出数据流图，确保每条箭头都有明确的协议（Kafka、gRPC、HTTP）和压缩率。
  5. 准备一份“成本‑效益对照表”，列出常见技术选型的月度费用、运维复杂度和容错程度。
  6. 复盘最近一次面试的feedback，找出自己在“权衡取舍”环节的薄弱点，并针对性做案例演练。
  7. 了解Dream11 2026年的薪资结构：Base $150K‑$220K，RSU $120K‑$250K/年，Annual Bonus $20K‑$40K。准备好对期望薪资的阐述逻辑。

常见错误

错误一：只罗列技术栈

  • BAD：“我们可以用Kafka、Flink、Redis、Kubernetes、Prometheus来搭建系统。”
  • GOOD：“我们先把业务拆成‘实时比分采集’、‘状态计算’、‘缓存推送’三大块。采集层使用Kafka保证高吞吐，处理层选Flink因为它支持窗口计算并且可以在5秒内完成状态更新，缓存层用Redis因为热点比分的读取频率极高且需要TTL。每块的选型背后都有容量和成本的计算支撑。”

错误二：忽视业务指标

  • BAD：“系统需要高可用，采用多可用区部署。”
  • GOOD：“业务要求在5秒内把比分推送到99%活跃用户，故我们把SLA设为99.9%请求在4秒以内完成。为达成该目标，必须在每个可用区放置一个Redis读写分离集群，并使用CDN边缘节点做WebSocket代理，以降低网络抖动。”

错误三：在成本讨论时回避

  • BAD：“如果预算足够，我们可以直接买全托管的Kafka服务。”
  • GOOD：“目前预算上限是每月$30K。若使用AWS MSK，按3节点算每月约$9K；再加上Flink托管和Redis集群，总计约$27K，仍在预算内。若改用自建Kafka，运维成本会提升约15%，但可以在年度预算中节约$5K用于缓存扩容。”

FAQ

Q1：面试中如果遇到“请你在10分钟内给出容量估算”，我该怎么快速回答？

A1：先抓住三个关键数字：预计并发用户数、每秒事件产生量、每秒读取量。以Dream11的IPL决赛为例，峰值并发180万，比分事件每秒约2000条，平均每条需要推送到30%活跃用户（约54万）。于是计算出Kafka写入吞吐约2000 TPS，Flink处理2M记录/秒，Redis读取约30万 QPS。把这些数字直接写在白板上，并标注对应的实例规格（如Kafka 3×m5.large、Flink 4×c5.xlarge、Redis 6×r5.large），即可在时间紧迫的情况下展示量化思考。

Q2：HR在谈薪时常把Base、RSU、Bonus拆开，我应该怎么回应？

A2：先确认公司给出的区间：Base $150K‑$220K，RSU $120K‑$250K/年，Bonus $20K‑$40K。然后依据自己的经验价值和市场对标，给出一个整体包的期望，例如“我期望的整体年薪在$380K左右，其中Base $190K、RSU $180K、Bonus $30K”。如果HR只关注Base，提醒对方“不是只看Base，而是整体包的长期激励更能体现价值”，并说明RSU的归属期与岗位贡献挂钩。

Q3：如果在系统设计环节被问到“如果流量翻倍怎么办”，我该怎么回答才能体现前瞻性？

A3：先说明现有设计的伸缩点：Kafka采用分区扩容、Flink作业支持水平扩展、Redis使用Cluster模式。然后给出具体的扩容步骤：将Kafka分区从12提升到24，Flink增加Task Manager节点数两倍，Redis在Cluster中再加入3个节点并重新平衡槽位。最后补充监控与自动化：使用Prometheus监控吞吐和延迟，设置报警阈值，一旦CPU或网络利用率超过70%自动触发水平扩容脚本。这样展示了 不是等流量危机出现后再手动调优，而是提前在架构层面预留弹性。

准备好系统化备战PM面试了吗？

获取完整面试准备系统 →

也可在 Gumroad 获取完整手册。