题目重点：上传、处理、CDN和动态Feed的增长预算，明确发布状态、幂等、删除传播和降级取舍。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 教学功能为用户上传图片、关注和读Feed，公共图片经CDN；私有内容需单独访问控制，不能因增长默认公开。
- 以下DAU、上传率、大小、读取量是假设容量，不冒充题目流量；先确认峰值/地域/保留期。
- 身份、社交图、题目描述metadata与图片对象分开；训练允许处理中的图片稍后可见，若要求立即发布需改验收合同。
解题路线
- 容量先拆上传写、图片存储、变体处理、Feed读取与图片下载。百万DAU每人每天0.2上传是20万图/day，2MB原图约400GB/day，不含副本/变体；每人读100张图是1亿次/day，两条流量路径数量级不同。
- 客户端直传对象存储的限时签名地址减应用代理带宽，申请uploadID绑定用户、类型/大小限额、对象key。完成事件验证对象后入处理队列，thumbnail/transcode/扫描流水线按uploadID+版本幂等，重试不产生重复题目描述。
- 发布状态用initiated/uploaded/processing/ready/failed/deleted等明确转移。metadata与对象跨服务非同事务，靠幂等事件/outbox或对账补偿保证可恢复；CDN能拿到文件不等于metadata已ready。
- 热图用CDN与多尺寸变体，cache key包含不可变对象版本；源站回源控制、prewarm与热点复制均按成本取舍。signed URL过期、私图授权与撤销不能靠公共cache长期保存的旧URL解决。
- Feed按follow graph取候选，普通用户fanout on write给读低延迟，超大粉丝作者fanout on read或混合避免写放大。排序/分页用稳定游标与排序键；重复事件、删除和读快照须定义，offset分页可能漂移。
- 大幅增长前做负载阶梯与故障演练：分开队列延迟、处理CPU、DB热点、CDNhit、源站带宽、Feedp95。处理积压可先只生成必要缩略图，推荐降级时间序Feed，上传超限明确拒绝/延后，不默默发布坏图。
- 删除/审核先让metadata不可见，再传播对象与CDN失效/短TTL，保留tombstone阻止旧重试复活。容量增加不解决错误可见范围、越权或删除复活；这些应成为独立状态不变量。
手动走一遍
假设20万图/day×2MB=400GB原图/day，保留30天约12TB原始量，副本/变体另加；1亿次/day每张展示200KB约20TB/day边缘输出，平均约231MB/s十进制。若10倍峰值，先用CDN命中率估回源：99%命中只约2.31MB/s平均回源，但上传400GB/day与处理队列仍独立存在，不能拿高CDNhit证明写路径够用。
规模与取舍
Feed写放大随作者粉丝数，fanout read随查询候选数；图片处理随像素数/格式，不只文件bytes。数据增长按保留期/副本/变体/索引累计，流量以峰值和缓存miss separately预算；以上是估算而非吞吐实测。
易错点与追问
容易失分的边界
- 原图全部走应用server。
- 只算metadata不算图带宽。
- 对明星作者全量写fanout。
- 重复处理事件发布多帖。
- 删除后重试复活。
- 签名URL等同永久私图权限。
继续深挖
- 如何对账对象存在但metadata失败？
- 私有图片CDN缓存如何授权与撤销？
- 超大粉丝账户Feed怎样混合？
- 处理队列积压怎样降级与限流？
