后端方案表达适用边界先讲清面试、评审或技术分享中方案可信度来自约束、取舍和证据而不是复杂组件数量。没有真实数据时不要编造 DAU、QPS 或延迟可以说明当前已知条件、尚未测量的部分以及准备如何验证。一种清晰的表达顺序业务动作与正确性要求例如结果是否允许延迟可见、是否允许重复。当前规模与假设流量、数据量、读写比例、可用资源未知项明确标注待测。选择的方案及替代项为什么先用数据库索引或缓存何时需要队列、分片或一致性协议。代价与风险缓存一致性、运维复杂度、数据恢复、供应商依赖。验证计划压测脚本、观测指标、容量上限和降级策略。示例当前先使用索引与进程内缓存原因是读多写少且数据量可控。 若命中率下降或数据库等待达到预设阈值再评估共享缓存阈值由压测和 SLO 确定。限流器可以保护下游但“每秒计数”并不等于准确 QPS更不能证明尾延迟达标。分布式服务应使用网关或共享限流能力并以滑动窗口、令牌桶等策略匹配业务本地计数更适合作为单实例保护。例如某个接口允许短时间突发但数据库连接有限固定窗口计数可能在窗口边界放过两批请求令牌桶通常更贴合这种需求但令牌速率和突发量仍要由下游容量推导。展示压测时同时给出工具版本、请求集、并发模型、环境配置和结果。这样即使结果不理想也能说明方案正在被严谨验证。
