服务型小程序的并发压力很少表现为全天候的流量。真正困难的是可预期的短时高峰：家政保洁类业务的订单高度集中在周末早晨的两三个小时，同一时刻几十上百个预约请求涌入，而每一次下单都不是单纯的读操作，而是对“某位阿姨某段时间”的抢占。把这一点看清楚，架构的重心就会从扩容转移到写路径的设计上。
先解决档期占用，再谈派单
重复派单是这类系统最典型的线上事故：两位客户同时选中同一位阿姨，各自看到的排班表都是空闲，最终都下单成功。根因不在于查询慢，而在于校验与写入之间存在窗口。正确的做法是以“阿姨 + 具体时段”为粒度做原子占用，而不是以订单为粒度加锁。家政的时段边界并不整齐，一单可能两小时、三小时或四小时，阿姨一天可能跑三家，跨时段占用、临时请假、改约加钟都要在同一套档期模型里表达。如果为了省事把时间切成“上午/下午”两段，高峰期的锁粒度就会过粗，可用运力被大量虚拟占用，实际运营立刻失衡。
锁的持有时间同样关键。同步链路只应回答“这段档期能不能占”，把距离计算、评分排序、技能匹配这些耗时判断推到占用成功之后异步完成。派给谁更合适属于优化问题，能不能占属于正确性问题，两者的失败代价完全不同。
把外部依赖挡在关键路径之外
就近匹配依赖地理围栏与距离计算，还往往要调用外部地图服务。这类调用按量计费、响应存在波动，一旦放进下单事务里，高峰期的尾延迟会直接传导成下单失败。可行的结构是提前把阿姨的服务范围做预计算并缓存，实时环节只做粗筛和精排；外部调用超时或失败时降级为规则排序，让订单先落地，再由后台补偿调整。派单结果允许事后修正，用户的下单动作不应该被一个第三方接口卡住。
与派单同等重要的是状态一致性。支付回调、派单结果通知、阿姨接单确认都会重试，重复消息不能造成重复扣款或重复占档，订单状态迁移必须有明确的前置状态约束。押金与分账链路涉及外部支付机构的预授权能力，边界在己方系统之外，更要在本地维护一份可对账的状态。
容量评估的口径也需要修正。按日均单量估算资源，几乎必然低估峰值：应当拆解高峰时段的同时下单数、每单涉及的写操作次数、以及调度计算的耗时，再倒推余量。低价方案常见的失效点正是这里——平时跑得动，一到集中时段就卡顿，甚至出现两位客户抢到同一位阿姨。补这块要花钱，但比事后处理客诉和退款便宜得多。
高并发的成本从来不是均匀分布在整个系统上的。对服务型小程序而言，优先做对档期占用与结算这两条写链路，收益远大于无差别地增加机器。
