题目重点：按题目第二轮 Staff Architecture 追问，准备系统图、关键路径、模型版本、编排和失败恢复，逐层说明自己实际做过的取舍与证据。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 候选人选择自己真正负责过的复杂架构，画出端到端请求与离线训练/配置链路；任何组件名、数字和取舍都以实际系统为准。
- 本文的 200ms p95 总预算示例只用于展示如何拆分关键路径，不是 Uber 或作者项目数据；只有面试者有真实测量时才能作为自己项目的结论。
解题路线
- 用一张系统图标出入口、认证、特征/数据、模型服务、规则或后处理、持久层和外部依赖；对每条箭头写同步/异步、协议、数据契约、所有者与超时。先说用户请求路径，再说训练/部署路径，避免两个图混在一起。
- 把 p95 延迟拆为串行关键路径与并行分支：例如入口 15ms、特征并行的最大分支 45ms、模型 80ms、后处理 20ms、网络缓冲 40ms，合计 200ms；这些是假设算例，实际还需关注尾部相关、队列等待和跨区 RTT，不能简单把每层独立 p95 相加当真实 p95。
- 逐个组件回答为什么存在：模型为何选该结构、特征为何在线或离线、数据多久刷新、缓存何时失效、训练与服务如何保证特征定义/版本一致。拿得出基线比较、离线评估与线上回滚证据，不能只报模型名称。
- 解释 infra orchestration：部署单元、资源配额、自动扩缩条件、模型制品与配置版本、灰度发布、健康检查、失败重试、跨区域和数据回填。说明一次模型升级时数据 schema、模型、服务代码如何兼容及谁批准切换。
- 最后讲失败链路和个人取舍：模型超时用什么降级、特征缺失是否安全、依赖服务局部故障如何隔离、谁 oncall；当准确率和延迟冲突时如何用数据做决策。准备一两个自己曾改错设计的例子，比只描述理想架构更可信。
手动走一遍
面试官问‘这个模块为什么要单独服务化’：先说明当时的不同扩容节奏或所有权，再展示请求路径、p95 和错误预算的测量，比较内嵌库/独立服务两个备选的运维代价；最后说实际决定及上线后的证据。若数据不可公开，可用相对变化与范围，但须明确测量窗口。
规模与取舍
规模应覆盖 QPS 峰值、模型实例显存、特征读取量、缓存命中、跨区流量和训练数据增量。若每请求做 C 次远程特征读取，最坏远程请求率约 QPS×C；批量化可减少网络往返，但特征服务和缓存仍需按峰值/热点分片容量验证。
易错点与追问
容易失分的边界
- 只展示漂亮架构图，无法说出任何模块的延迟、错误率、成本或故障处理。
- 把各组件 p95 相加当系统 p95 的精确值，忽略相关尾部和排队；应以端到端实测校准。
- 说‘用了某模型/编排平台’却解释不了它解决什么约束、部署如何回滚、训练服务如何对齐版本。
- 给出自己并未亲自参与的决策细节或编造指标；面试官逐层追问会迅速暴露证据缺口。
继续深挖
- 如果下游模型服务容量下降一半，哪些请求能降级，哪些必须失败？如何防止重试风暴？
- 特征 schema 新版本上线时，如何让旧模型继续读旧字段直到安全切换？
- 当一个项目含多个子项目，怎样说明共同平台与各子项目的所有权边界和决策过程？
