题目重点：Nvidia DGX Cloud VO 面经要求设计 photo view app、扩容与实用的 oncall/monitor；本文给出可核对的需求假设、读路径、容量估算和故障处置。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版核心功能是按 photo_id 查看原图和缩略图，以及查看用户自己的照片列表；上传用于让内容进入系统，是补充的最小写路径。题目未明确出具体 API。
- 用示例规模作容量推演：1000 万日活、每人每日 20 次查看，约 2 亿次/日、平均约 2315 次/秒；峰值按平均 10 倍约 2.3 万次/秒。数值是训练假设，不是 Nvidia 负载。
- 照片平均原图 3 MB、缩略图 100 KB；每日日增 100 万张则原图约 3 TB/日，未计副本与转码。私有照片必须先鉴权，公开照片可更积极缓存。
解题路线
- 先问清查看路径：GET /photos/{id}/metadata 返回 owner、权限、版本和可用尺寸；服务鉴权后签发短时下载 URL。图片字节放对象存储，经 CDN 分发；元数据单独保存在可索引的数据库，按 owner_id+created_at 支持列表分页。
- 训练写路径先获得上传授权，把原图写入对象存储，再异步生成缩略图并更新状态为 ready。转码任务用 photo_id+version 做幂等键；失败重试与死信队列可恢复。查看未完成时返回处理中占位，不把不存在与处理中混为同一错误。
- 扩容时分别量测元数据读、对象存储吞吐、CDN 命中率和转码队列积压。图片读多写少，优先通过 CDN 降低回源；元数据热点用短 TTL 缓存并在删除或权限变化时失效。大规模用户列表可按 owner_id 分区和游标翻页。
- oncall 先围绕用户可见症状设 SLI：查看成功率、p95 首图时间、缩略图 ready 延迟、CDN 5xx 与回源率。告警绑定 SLO 和持续窗口，配 runbook：确认区域/版本、比较 CDN 与源站、回滚发布或切流、排查对象存储与转码积压、事后补算受影响请求。
手动走一遍
用户打开 photo_id=42：API 查元数据并核对可见性，返回指定尺寸的短时 URL；浏览器从 CDN 获取缩略图，必要时再拉原图。若转码队列积压，原图仍可按策略展示，缩略图显示处理中并重试；oncall 会同时看到 ready 延迟升高和队列年龄变长。
规模与取舍
按假设的 2 亿次查看/日、缩略图 100 KB，若全部走缩略图约 20 TB/日出口流量；CDN 命中率 90% 时源站该部分约 2 TB/日。原图请求占比、跨区域复制和缓存命中率会大幅改变成本，应通过实际访问分布重新估算。用户列表查询目标为索引范围扫描 O(log P+K)，P 为该用户照片数、K 为页大小。
易错点与追问
容易失分的边界
- 把图片二进制直接放元数据库，忽略对象存储、CDN、回源成本和缓存失效。
- 私有照片只靠难猜的 photo_id 保护，或将长期公开 URL 缓存到 CDN，导致权限撤销后仍可访问。
- 只监控服务 CPU 和 5xx，却不看首图时间、转码积压和 CDN 命中；用户体验可能已坏而告警未触发。
- 展开 feed timeline 排序、社交图或推荐系统；题目明确说该轮没有讨论它们。
继续深挖
- 若面试官要求私有照片删除立即生效，比较短 URL TTL、CDN 主动失效与回源鉴权的安全和延迟取舍。
- 若多区域查看占主流，讨论图片复制、就近 CDN、元数据主写区域与跨区故障降级。
- 若持续流量突增，先保护鉴权和元数据服务，再扩大 CDN 缓存与转码 worker；runbook 应包含按症状回滚和限流阈值。
