题目重点：DoorDash MLE 系统设计题目深挖：User ID 与定位、营业/配送硬过滤、Geo 缓存、并发召回、特征存储及 V2 A/B 实验。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 可见题目的 15ms 是对每路召回的假设追问，不是已知整条请求的端到端 SLO。训练契约额外假设整体 P95 预算 100ms，仅用于示范预算分配。
- 营业与配送范围是最终返回前必须核验的硬规则；Geo 网格热榜只提供候选，不能把离线缓存中的营业状态视为实时权威。
- User ID 可缺失或新用户；地理位置精度受隐私设置与定位误差影响。缺用户特征时用位置/时段/热度兜底。
解题路线
- 请求入口拿 User ID、坐标、时段与实验桶。用粗网格/Geohash 热榜、历史偏好和相似店铺等并行召回；每路限候选数和 15ms deadline，慢路超时就舍弃该路而不拖死整次请求。
- 合并去重候选后，用实时营业状态、配送服务区域、可用容量等规则做硬过滤；对网格边界扩邻格召回，最后仍计算精确服务范围，避免网格近似造成漏/误收。
- 特征服务按 (entity_type,entity_id,feature_view_version) 组织：用户和店铺特征分开，embedding/数值/类别可用各自存储与批量读取路径。离线小时级刷新带 event_time/last_updated；实时特征只用于收益能覆盖延迟与缺失风险的少数关键项。
- 排序服务在请求开始固定 model/feature config 版本，按实验桶获取 V1 或 V2 特征集合并批量拉取；缺字段使用训练期一致的默认值并记录 missingness，防止在线离线口径漂移。最终做多样性/业务规则重排并记录曝光。
手动走一遍
用户 U 位于网格 G，G 与邻格预计算热榜给 200 个候选，偏好路给 50 个；两路并发，15ms 内回来后合并去重。某店因已打烊被硬过滤，即使排序分数最高也不能展示。U 被分到 V2 实验桶，服务只加载 V2 声明的新增特征；若某实时特征超时，按配置默认值推断并打缺失日志，而不是偷偷退到 V1 模型。
规模与取舍
若 R 路并发召回、合并候选 K、排序特征维度 F，合并去重 O(K)、硬过滤 O(K)、批量特征与模型成本约随 K×F 增长；实际延迟由最慢的成功召回路、批量读放大和模型推断决定。地理热榜存储约为网格数 × 每格候选数，需控制密集城区热格。
易错点与追问
容易失分的边界
- 只用 Geohash key 过滤配送范围会把相邻网格的近店漏掉，也会收进同格但不配送的店；粗召回和精确规则校验要分层。
- 所有召回路都等待满 15ms 再串行合并、读特征会突破整体延迟预算；fan-out 并发、连接池、批量 fetch 和 deadline 传播要一起设计。
- V2 新增特征但在线仍读 V1 schema，会出现 silent null；实验桶应固定 model 与 feature config 版本，并有兼容期与回滚路径。
- 离线小时级特征不能冒充实时营业状态；特征值的 freshness 和权威规则的 freshness 是两个指标。
继续深挖
- A/B 评估同时看下单转化、完成率、取消、ETA、商家曝光公平性与延迟/超时率；只看 CTR 可能提高点开却损害履约。
- 实时特征若变热键，可按实体分片与缓存微批更新；观察真实增益、缺失率和 P95/P99 后再决定是否保留。
- 对新用户无历史画像，回退到位置/时段热榜与探索；对定位权限关闭用户，应定义粗区域或手填地址流程。
