分布式存储设计题：用明确排除范围来聚焦真正要解决的核心问题

微博Feed分布式存储的设计训练题给出了一个值得学习的出题方式：在描述完业务场景（查询用户收到的新微博需要聚合所有关注对象的最新发表、查询用户profile需要支持按页或按时间段跳转分页、访问热点高度集中在最近几天的数据）之后，明确列出了几项”不需要考虑”的范围——不需要设计缓存层（缓存放在业务服务层）、不需要考虑应对写入峰值（微博本身可以走队列异步入库来错峰）、不需要考虑分布式主键ID的生成方式（假定已有现成的发号服务）、不需要考虑用户收到的微博如何聚合（这是业务服务层的职责）。这种”先划清楚边界、再谈设计”的方式，本身就是一种值得迁移的架构思考习惯：任何一个足够复杂的系统设计问题，如果不先明确”这次要解决的核心矛盾是什么、哪些相邻问题已经被其他层解决、不需要在这一层重复考虑”，很容易陷入试图一次性解决所有问题的陷阱，导致方案本身臃肿且难以评估优劣。这道题把问题聚焦在存储层本身该如何设计上——具体说就是如何组织海量、持续增长、访问热点高度集中在近期的Feed数据，让这个核心矛盾能被单独、干净地讨论，而不被缓存策略、写入峰值应对、ID生成这些本该属于其他层的关注点稀释。