题目重点：Mobile Power Day SD 题目点出实时汇率 dashboard 与 cache、multithread、view、pagination、database；以可见报价和更新路径展开。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版是展示汇率的 dashboard，不承诺用户可按显示价交易；若涉及交易报价，需单独定义锁价与有效期。
- 每条汇率有 base/quote、source、asOf 时间与 stale 状态，展示前需确认币种小数精度和时区。
解题路线
- 先问显示多少货币对、更新频率、用户规模与离线体验，确定‘实时’可接受的最大陈旧度与刷新延迟。
- 报价摄取端校验来源、时间戳、异常跳变与重复更新，保存最近可信快照和历史序列；按币种对聚合读模型。
- 移动端首次读缓存快照，再用 WebSocket/SSE/定时拉取增量；断线后以版本号补齐，旧时间戳不得覆盖新报价。
- 缓存键按币种对/报价版本，配置 TTL 和 stale 标记；服务端不得把陈旧值无提示展示为当前价。
- UI 分页/虚拟列表只渲染可见币种对，搜索/排序在明确定义的同一快照上做；后台更新在异步 worker 合并，主线程负责平滑更新视图。
- 估算货币对数×更新频率×历史保留期，再看推送 fanout、客户端电量、数据库写入和缓存命中；监控源延迟、stale 比例、断线补偿和帧率。
手动走一遍
训练例：EUR/USD 在 10:00:01 得到 version 8，10:00:02 网络重发 version 7；客户端保留 8。用户离线 30 秒后看到 asOf 及陈旧标记，重连按 8 之后增量同步，不将旧值误认为实时。
规模与取舍
摄取写入与更新事件数成正比；面向 U 个同时在线客户端的直接 fanout 最坏 O(U×更新数)，可按订阅币种对分组。题目无容量与 SLA，不能给固定服务器数。
易错点与追问
容易失分的边界
- 把‘实时’写成无上限轮询而不定义新鲜度。
- 异步旧响应覆盖更新的报价。
- 缓存命中却不显示 asOf/陈旧状态。
- 让主线程完成大量合并/排序造成卡顿。
- 无题目依据地扩展成交易撮合系统。
继续深挖
- 报价来源冲突时怎么选？
- 离线客户端恢复后如何补数据？
- 列表筛选和分页遇到持续更新时如何避免跳项？
- 若要交易锁价需要新增什么状态？
