SeaPM系统设计面试思路与真题解析2026
Sea的系统设计面试不是考你会不会画架构图，而是考你在东南亚复杂网络环境下，能不能用有限资源做出可落地的 trade-off。这个判断本身，和 Google、Meta 的考法就不是一回事。
一句话总结
Sea PM 的系统设计面试核心就三句话：第一，东南亚基础设施的脆弱性不是背景噪音，而是你架构里的核心约束条件；第二，面试官不是在看你能不能把系统做大，而是看你能不能在现场把系统"做脏"再逐步 clean up 的决策链条讲清楚；
第三，Shopee、Garena、SeaMoney 三条业务线的系统设计题各有暗门，用同一套模板硬套的候选人，往往在第二轮就被标记为 "no hire"。
适合谁看
这篇文章是给已经拿到 Sea PM 面试通知、正在准备系统设计轮的人写的。不是给还在投简历的人看的入门指南。
具体来说，你是这样的人：你大概有三到五年产品或技术背景，可能在字节、阿里、腾讯做过电商或支付相关项目，也可能在东南亚本地公司如 Grab、Tokopedia 待过。你对系统设计的认知还停留在"画个微服务架构图，讲讲负载均衡和缓存"的阶段，或者你把 Google 的 System Design Interview 那本书背得滚瓜烂熟，却发现 Sea 的面试官根本不按那个套路出牌。
你需要的是针对 Sea 业务语境的、能在面试现场直接用的判断框架。
另一类人是在海外读 CS/MBA、想回东南亚发展的候选人。你对北美大厂面试套路熟悉，但对 Sea 内部的技术债、组织张力、业务优先级缺乏体感。你容易犯的错是把 FLAG 的解法直接搬过来，比如默认 CDN 覆盖全球、假设支付网关稳定可靠，这些在 Sea 的面试里都是扣分项。
还有一类是 Sea 内部转岗的 PM，从 Shopee 转 Garena，或从 Garena 转 SeaMoney。你以为内部转岗面试会放水，但系统设计轮的面试官往往是跨 BG 的资深架构师，他们对"自己人"的拷问反而更直接。你需要的不是 more prep time，而是知道对方会问什么以及为什么这样问。
Sea 的系统设计面试到底在考什么：不是架构完整性，而是约束条件下的取舍
很多人把系统设计理解成"把系统做大"，Sea 的考法是"把系统做活"。
东南亚不是美国。印尼的 4G 覆盖在 2024 年还有大片空白，菲律宾的移动支付渗透率至今低于中国 2015 年的水平，越南的跨境结算需要绕过 SWIFT 的替代方案。这些不是你在面试结尾"顺便提一下"的加分项，而是你的架构必须从第一根线开始就围绕它展开的核心变量。
一个真实的 debrief 场景：2024 年 Q3，一个候选人在 Shopee 物流系统的系统设计题里，花了十五分钟讲如何用 Kafka 做订单状态机，讲得头头是道。面试官问，如果印尼某岛的基站断联 6 小时，骑士端 App 的离线状态怎么同步？候选人愣了一下，说"那等到网络恢复再同步吧"。
这个回答直接导致他在 feedback 里被打上 "insufficient operational thinking" 的标签。不是他技术不行，而是他没理解 Sea 的系统设计题本质是 operational design，不是 textbook architecture。
Sea 的面试官有一个不成文的评分维度，叫 "regional feasibility"。你的方案能不能在雅加达郊区的机房跑起来，比你的方案能不能支持百万 QPS 更重要。
这不是说高并发不重要，而是高并发在 Sea 的语境里有具体的业务含义：Shopee 的大促峰值、Garena 的游戏开服、SeaMoney 的发薪日转账，这些场景的高并发是带着地域脉冲特征的，不是均匀分布的。
另一个关键判断：Sea 的系统设计面试不是单轮定生死，而是连续三轮的累积评估。第一轮通常是基础架构设计，考察你能不能快速抓住核心实体和关系；第二轮是深度扩展，给一个新约束让你现场改架构；
第三轮是跨系统联动，比如让你把 Shopee 的订单系统和 SeaMoney 的支付链路打通。三轮的面试官会互相看笔记，你在第一轮说过的假设，第三轮会被拿来追问一致性。所以"现场编"是致命的，你的架构必须有可回溯的逻辑链条。
> 📖 延伸阅读：Sea应届生SDE面试准备指南2026
为什么东南亚语境是隐藏考题：不是考你知道多少，而是考你默认什么
这是 Sea 系统设计面试最反直觉的地方。面试官不会问你"东南亚网络怎么样"，但你的方案如果默认了北美或中国的基础设施水平，会在无形中暴露盲区。
一个具体的 hiring manager 对话场景：2025 年初，一位从蚂蚁金服过来的候选人在 SeaMoney 的系统设计面试里设计了一个实时风控系统，用了大量的 Flink 实时计算和 Redis 集群。面试官问，如果菲律宾某城的机房因为台风断电，你的风控规则怎么降级？候选人说"我们有异地多活"。
面试官追问，异地多活的 RPO 是多少，你们愿意接受多少坏账率来换取可用性？候选人开始绕圈子。事后 hiring manager 在 1-on-1 里说，"他知道怎么做风控，但他不知道怎么做菲律宾的风控"。
这个案例的要点在于：Sea 的系统设计面试里，"不知道"本身不是硬伤，但"不知道却假设别人帮你解决"是硬伤。正确的做法是在设计之初就明确标出你的 assumption 和对应的 fallback，比如"我假设核心机房的可用性是 99.9%，低于这个阈值时，风控降级为规则引擎离线评分，牺牲 5% 的精度换取 100% 的可用性"。
这种表达不是示弱，而是展示出你对不确定性的管理能力。
另一个常见的盲区是支付链路。SeaMoney 覆盖多个国家，每个国家的监管要求、主流支付方式、清算周期都不同。候选人在设计支付系统时，容易犯的错误是把"多币种支持"当成一个功能点加在后端，而没有意识到它在架构层面会驱动账务模型、对账机制、甚至客服工单系统的设计。正确的做法是，在实体建模阶段就把"国家"作为一等公民，而不是一个字段。
真题拆解一：Shopee 订单履约系统的实时追踪
这道题在 2024-2025 年的面试中出现频率极高，但答得好的人不多。
题目通常这样给：设计一个系统，让买家能实时看到包裹的位置，同时骑士端能在弱网环境下更新状态。
BAD 版本：候选人上来就画三层架构，App -> API Gateway -> 微服务集群，然后讲怎么用 GPS 采集位置、怎么存到 MongoDB、怎么通过 WebSocket 推给客户端。这种答法的致命问题是把"实时"当成技术问题，而不是业务问题。
GOOD 版本：先定义"实时"的业务含义。对买家来说，包裹在仓库时更新频率可以低，但在最后一公里需要秒级；对骑士来说，位置上报的频率取决于网络条件和电量，不是越频繁越好。
然后给出约束分层：核心轨迹用 GPS + 基站双源，弱网时降级为骑士手动触发或基于配送路线的预测位置。存储上，热轨迹用 Redis 集群按地理分片，冷轨迹按天归档到 S3 兼容对象存储。推送上，城市内用自建 MQTT broker，跨城或跨国时用 Sea 内部的消息总线做异步聚合。
关键判断在这里：不是"实时性越高越好"，而是"不同阶段的实时性成本收益不同"。这个判断需要你在面试现场快速做出，并且用数字支撑。比如你可以说，最后一公里 10 秒更新一次，电池消耗增加 30%，但客服投诉下降 15%，我们判断这个 trade-off 值得做。
> 📖 延伸阅读：Sea内推攻略：如何拿到产品经理内推2026
真题拆解二：Garena 游戏好友系统的跨服互通
Garena 的系统设计题有一个特点，它经常让你设计一个"看起来简单"的系统，然后往深处挖。
这道题的原型是：Free Fire 有多个大区，玩家希望跨服加好友、看状态、组队。怎么设计？
BAD 版本：候选人直接套用微信的架构，做一个全局的关系型数据库，所有好友关系存在一起，用分布式事务保证一致性。这种答法在 Garena 的面试里会直接被判死刑，因为游戏大区的设计初衷就是隔离故障域，全局数据库违背了基本设计原则。
GOOD 版本：先明确业务目标。跨服好友的"好友关系"和"游戏内组队"是两个不同的一致性要求。好友关系可以最终一致，延迟几秒没关系；
但组队匹配需要实时确认对方在线状态，这个不能含糊。所以架构上分两层：好友关系用基于 CRDT 的冲突自由数据结构，各服异步同步，冲突时以时间戳或用户显式操作为准；在线状态和组队邀请用区域级协调服务，跨服时走信令中继，不依赖全局状态。
一个 insider 细节：Garena 的面试官特别喜欢追问"如果两个玩家同时向对方发好友请求，怎么处理"。这不是在考你算法，而是在考你对 edge case 的敏感度。正确的回答不是"加锁"或"用唯一索引"这种技术答案，而是先问业务规则：这两个请求算一个关系还是两个？如果算一个，谁的身份是"发起方"？这个问题没有标准答案，但你的追问本身就在展示产品思维。
真题拆解三：SeaMoney 数字钱包的余额与账务分离
这道题是 SeaMoney 系统设计面试的"保留节目"，也是最能区分 candidate quality 的一道题。
题目背景：设计一个数字钱包系统，支持充值、提现、转账，同时满足东南亚多国的监管审计要求。
BAD 版本：候选人设计了一个大表，用户 ID、余额、流水存在一起，每次交易更新余额并插入流水。这种设计在中国早期的支付系统里不少见，但在 Sea 的面试里会被直接标记为 "junior"。问题不在于性能，而在于这种设计无法满足监管要求的分账、冻结、回溯，也无法处理充值失败但用户已看到成功提示的 race condition。
GOOD 版本：严格区分"余额视图"和"账务核心"。余额视图是用户看到的数字，可以容忍短暂不一致，用缓存加速读取；账务核心是监管眼中的真相，必须满足会计恒等式，用事件溯源保证不可篡改。
充值、提现、转账都抽象为"指令"，指令进入队列后由账务核心按序处理，处理完成后异步更新余额视图。对于监管要求，每个国家单独配置审计规则，比如印尼要求实时上报大额交易，菲律宾要求 T+1 对账，这些规则作为插件挂在账务核心的事件流上，不侵入主流程。
这个设计的核心判断是：不是"让用户看到正确的数字"，而是"让监管看到正确的数字，让用户尽快看到数字"。这两个目标的解耦，是支付系统设计的分水岭。
面试流程全拆解：每一轮都在淘汰"看起来还行"的人
Sea PM 的系统设计面试通常是 4-5 轮，但系统设计本身可能分散在 2-3 轮里，和其他考察维度交叉。
第一轮：Hiring Manager Screen（45 分钟）。不是系统设计，但会埋雷。HM 会问你最复杂的项目，如果你提到涉及系统架构的，他会追问几个关键决策。这一轮的目的是筛掉简历造假和沟通有问题的，不会深入技术细节，但你的表达不清会导致后续没有面试机会。
第二轮：System Design I - 基础架构（60 分钟）。给你一个明确的业务场景，要求设计核心实体、API 和基础数据流。这一轮的关键是"快"，你需要在 10 分钟内让面试官理解你的整体思路，剩下的时间深入 1-2 个点。考察重点：抽象能力、边界识别、是否能在信息不完备时做合理假设。
第三轮：System Design II - 深度扩展（60 分钟）。基于第二轮的方案，增加一个强约束让你现场改。常见套路：量纲突变（用户从百万到十亿）、新增合规要求、或模拟一次故障需要你设计降级方案。这一轮考察的是架构的弹性和你的应变逻辑，不是原方案的完备性。
第四轮：Cross-functional / Behavioral（45-60 分钟）。可能是工程师、设计师或运营同事，考察你和不同角色协作的能力。这一轮经常会出现"工程师挑战你的方案"的场景，不是敌意，而是设计好的压力测试。你需要展示的是如何基于共同目标说服或调整，而不是捍卫面子。
第五轮：Hiring Committee Review。这不是面试，但决定你的命运。HC 会看所有面试官的反馈，特别关注"red flag"——任何一轮出现诚信问题、极端沟通问题或能力模型不匹配，都会被一票否决。系统设计轮的反馈权重很高，因为 PM 在 Sea 的核心价值之一就是技术判断力。
薪资方面，2025-2026 年 Sea PM 的 package 大致如下：Base $120K-$200K（根据级别，Associate PM 到 Senior PM），RSU $40K-$150K 每年（4 年 vest，有 cliff），Bonus $20K-$60K（绩效挂钩，通常占 base 的 10%-20%）。总包区间大约在 $180K-$400K，Senior PM 或特殊引进人才可以突破。
这个水平和新加坡本地其他科技公司相比有竞争力，但和北美总部职位比仍有 gap，Sea 的卖点更多在业务增长速度和东南亚市场的 exposure。
准备清单
- 把 Shopee、Garena、SeaMoney 近两年的技术博客和事故复盘通读一遍，不是为了背答案，而是为了建立"这家公司关心什么问题"的体感。
- 找三个东南亚具体国家的网络、支付、物流基础设施数据，不是泛泛了解，而是能说出"印尼 4G 覆盖率在爪哇岛和外岛的差异"、"菲律宾 GCash 和 Maya 的市场份额变化"这种颗粒度。
- 准备一个"约束分层"的固定框架：每次系统设计先列业务约束、技术约束、监管约束，再开始设计。这个习惯能让你在压力下不遗漏关键变量。
- 系统性拆解面试结构，PM面试手册里有完整的电商/支付/游戏系统设计实战复盘可以参考，特别是关于如何在时间压力下做 depth vs breadth 取舍的部分。
- 找一位有 Sea 或类似东南亚公司经验的人做 mock interview，重点不是技术正确性，而是你的表达是否符合"先给结论、再讲依据、最后说 trade-off"的结构。
- 准备一个"失败案例"的 2 分钟版本，用于 behavioral 轮或压力测试。Sea 的面试官相信"你怎么谈失败"比"你怎么谈成功"更能预测未来表现。
- 面试前 24 小时停止新增信息输入，把已有的框架默念三遍，确保现场能自动化调用而不是现场拼凑。
常见错误
错误一：把"可扩展性"当成唯一目标
BAD：候选人在设计 Shopee 直播系统时，花了 20 分钟讲怎么用微服务拆分、怎么水平扩展，但从未提到东南亚各国的带宽成本差异和主播端设备性能参差。面试官追问"如果印尼主播用的是 2018 年出的千元安卓机，你的推流策略怎么调"，候选人完全没准备。
GOOD：在设计之初就定义"扩展"的多维含义。用户量扩展是一维，地域扩展是另一维，设备异构性是第三维。明确说"我的方案优先保证在低端设备上的可用性，牺牲 20% 的码率来换取 50% 的覆盖提升，具体数字可以在数据回传后调优"。
错误二：忽视监管和合规的架构影响
BAD：候选人在 SeaMoney 面试中设计跨境转账，提到"用区块链加快速度"，但当面试官问"印尼央行 2024 年新规对跨境结算有什么要求"时，候选人回答"这个可以让法务同事跟进"。
GOOD：把合规作为架构的一级输入而不是事后补丁。例如："印尼央行要求跨境资金必须经本地清算行，所以我们的架构在印尼节点增加一个合规网关，所有出境资金先到这里做申报，延迟增加 200ms，但这是不可协商的约束。"
错误三：在压力下改变核心假设却不告知面试官
BAD：候选人在第二轮扩展题里，为了回答一个新约束，把第一轮定义的"最终一致性"悄悄改成了"强一致性"，没有解释为什么这个改变是合理的，也没有提之前方案需要怎么调整。
GOOD：明确说"基于新约束，我需要调整第一轮的假设。之前我选择最终一致性是因为 X，现在 Y 条件出现了，我改为强一致性，代价是 Z，我的补偿措施是 W"。这种显式的 assumption management 是资深 PM 的标志。
FAQ
Q: 我没有电商或支付背景，主要是做 SaaS 的，准备 Sea 的系统设计面试是不是劣势很大？
不是背景问题，而是迁移能力问题。一个常见的误区是认为 Sea 只招"做过电商的人"，实际上 2024-2025 年 Sea 从 Salesforce、ServiceNow 等公司招了不少 PM，核心考察的是"你把通用系统设计能力映射到陌生业务域的速度"。具体做法：选三个 Sea 的核心业务场景，用你熟悉的 SaaS 设计经验重新解构。
比如你做过多租户 SaaS 的权限系统，这和 Shopee 卖家分级体系在抽象层面是相通的——都是"主体-资源-操作"的映射，只是业务语义不同。面试时主动说出这种映射关系，比硬补电商知识更有说服力。一个真实的 positive case：一位来自 Zoom 的候选人在 Garena 面试时，把实时音视频的网络自适应算法和游戏中的低延迟匹配做了类比，面试官在 feedback 里写"shows strong first-principle thinking"。
Q: 面试官给的场景信息很少，我是应该快速追问还是先做假设？
追问的质量比速度更重要，但追问的方向比质量更能暴露段位。初级候选人的追问是罗列式的："用户量多少？QPS 多少？预算多少？" 高级候选人的追问是结构化的："这个系统的核心成功指标是什么？
是延迟、可用性、还是一致性？因为不同指标会驱动完全不同的架构选择。" 另一个关键判断：如果面试官说"先不讨论这个"，不要纠缠，记下来作为你的 assumption 并在后续引用。例如"我假设峰值 QPS 是 10K，如果实际更高，我的扩展路径是..." 这种处理方式展示的是你在真实产品环境中的工作方式，而不是面试技巧。
Q: Sea 的系统设计面试和其他大厂相比，最大的不同是什么？
不是技术深度，而是"现场感"。Google 的系统设计面试可能让你设计一个全球搜索引擎，默认你有无限资源；Meta 可能让你设计 News Feed，关注算法和体验的平衡。Sea 的面试会让你设计一个必须在下周上线、但基础设施不稳定的系统，考察你在约束下的创造力 trickle-down 决策能力。
具体表现：Sea 的面试官更经常打断你，不是无礼，而是模拟真实工作中"需求变了"或"这个方案成本太高"的场景。你被挑战时的反应——是防御性解释还是协作式调整——是评分的重要维度。另一个具体差异：Sea 更接受"不完美但可落地"的方案，而不是"完美但无法执行"的架构。如果你在面试中说"这个方案在理想情况下如何如何"，而不加一句"在 Sea 的当前环境下，我会先做 X，因为 Y"，你的架构能力再强也可能被打折扣。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。