直接回答：容量估算（back-of-envelope）的目的不是算准，而是让设计决策有量级支撑：决定要不要分库分表、缓存放不放得下、带宽是不是瓶颈。方法四步：定输入（DAU、人均行为次数、数据条目大小）→ 换算 QPS（注意峰值系数，日均乘 2~3 得峰值）→ 算存储（条数 × 单条大小 × 保留时长 × 副本系数）→ 算带宽与缓存（热点比例决定缓存命中率需求）。
展开解析：必背数量级：一天约 10 万秒（8.64 万，估算用 10^5）；单机 QPS——Web 服务几千到几万、Redis 十万级、MySQL 几千；1 百万用户日活产生的内容型行为（发帖）按 1%~10% 渗透率；中文一条内容按 1~2KB 估；图片视频分别按 200KB、码率 × 时长。示例推演：1000 万 DAU 的信息流，人均刷 50 条 → 日均 5 亿次拉取 ≈ 6 万 QPS 均值、峰值 20 万，读链路必须缓存化；每条内容 1KB 元数据 + 图片外链，日增内容 100 万条 ≈ 日增元数据 1GB，一年 400GB，单机 MySQL 能扛两年但为运维与扩展应按用户分库。估算中的校验：两个路径各算一遍（自顶向下按用户、自底向上按机器）互相印证；对结果做敏感度分析（哪个假设翻倍影响最大，那就是设计里最需要留余量的环节）。面试呈现：边算边说出假设，让面试官能挑战假设而不是挑战你的算术。
追问方向：峰值系数怎么定？估算结论如何映射到具体的集群规模决策？
（约 490 字）