系统架构设计中最容易被低估的陷阱，不是技术选型，而是“信息过载”——多数从业者收藏了上百篇文章，却在真实项目中连基础的分层边界都画不清。

分层架构不是“三层”万能，而是“边界”决定取舍

最常见的场景是：一个中小型电商项目，技术负责人上来就画“表现层-业务层-数据层”三层图，结果业务层逐渐膨胀成“上帝类”，每增加一个促销活动就要改核心逻辑。真正有效的做法是，在分层时明确每层的“单一下沉职责”：表现层只处理HTTP序列化与用户输入校验，业务层应被拆为“应用服务+领域逻辑”两层，而非简单堆砌Service类。例如某支付系统将风控规则抽离成独立领域模块后，新增支付方式时，数据层只改一条配置，业务层无需触碰——这才是分层的核心价值。

高可用不是堆机器，而是“故障转移”的预设路径

某创业公司双11前自信地部署了8台服务器，结果一个数据库连接池泄漏，8台实例同步OOM。他们忽略了一点：高可用设计必须优先回答“某个节点挂了，系统如何继续服务”，而不是“如何让每个节点都不挂”。正确的做法是预设三类故障路径：进程级（心跳检测+自动重启）、网络级（客户端重试+熔断降级）、存储级（主从切换+数据补偿）。例如Netflix的Hystrix框架，核心就是为每个外部依赖预设“如果返回超时或失败，直接返回降级响应”，而非盲目增加副本。

缓存策略的命门：不是过期时间，而是“一致性窗口”

很多人以为缓存设计就是“查缓存-没找到-查DB-写缓存”，但忽略了最致命的场景：并发写操作下，缓存与数据库的“短暂不一致”会导致订单重复支付。例如一个库存扣减系统，若先更新DB再删除缓存，在极端时间窗口内，其他线程可能读到旧缓存库存并继续扣减，最终超卖。正确的做法是采用“延迟双删”（先删缓存、再写DB、再延迟删一次），或将写操作串行化到消息队列中。Facebook的缓存系统就用“租约机制”控制并发写入者，确保同一数据在同一秒内只有一个更新者。

避免踩坑的三条建议：
1. 设计初期必须画“数据流向图”，明确每个请求经过哪些中间件、每个写操作是否有幂等保证——别等线上出现重复扣款才补防重表。
2. 评估高可用时，先做“混沌测试”而非压测：随机杀死一个节点，看监控面板上的错误率是否超过0.1%，如果没准备降级预案，加再多服务器都是心理安慰。
3. 不要迷信“通用缓存框架”：Redis的穿透保护必须结合业务特征，比如对商品详情页缓存空值，但金融交易系统必须拒绝缓存空值，因为空值代表“数据不存在”而非“可降级”。