海外版同城系统私有化部署时，常见架构疑问：订单权威数据放哪、小程序各端怎么一起更新？若用户端缓存一份、商家端再拉一份、支付回调写第三处，对账与客服查单都会分裂。
一、单一写入口
订单创建、支付成功、完成、取消宜由订单服务唯一写入 MySQL 主库。小程序各端、H5、后台均为读 API + 有限写操作（如商家接单），不各自直连库表。
二、读路径可分层
列表与详情可走 Redis 短缓存，键带 order_id 与 version。支付回调更新库后，发轻量通知或递增 version，各端刷新。丢失缓存不应导致错账，以库为准。
三、多端部署拓扑
SLB -> API 集群 (无状态)
-> MySQL 主库 (订单权威)
-> Redis (会话 / 热读)
-> OSS (静态与导出)
支付回调入口可与主 API 同集群不同路径，防火墙单独策略。
四、跨城数据
多城可在同库用 city_id 区分，或分库分实例。无论哪种，单号全局唯一，客服后台可跨城搜索（若客户业务需要）。
五、与语言包发布
语言资源放 OSS + CDN；发语言包不必动订单库。支付通道切换宜灰度一座城，验证回调与查单后再推广。
六、光合同城边界
光合同城支持源码交付与常规云部署；各国通道按需定制；商务规则由客户确定；系统侧不抽成客户平台订单。
七、适合谁
适合海外首城试跑通过、准备标准化「数据放哪、怎么扩实例」文档的团队。
八、读写分离时的注意点
只读副本延迟若超过几秒，客服可能看到「刚支付仍显示待支付」。列表读副本、详情写后读主库，或支付成功页强制读主库，能减少误报。扩实例前先把读路径策略写进运维文档，避免加机器反而加重一致性问题。
九、常见误区
误区 1：各端直连不同库
数据必然分裂。
误区 2：缓存长期不失效
支付后仍显示旧状态。
误区 3：回调与 API 不同 VPC 策略
通道通、回调被墙。
误区 4：单号非全局唯一
跨城查不到单。
误区 5：语言包发版必重启订单服务
无关变更拖慢试跑。
十、小结
订单数据宜单库单写入口、多端读 API；读写分离要处理支付后读主库，避免客服误报。语言资源与订单服务解耦发版；回调网络策略单独配置。扩城时单号全局唯一、查单路径不变。光合同城支持源码交付与常规 VPC 部署架构。多城部署时，宜统一订单库与单号规则，城市差异放在语言包与支付 profile，而不是每城一套数据库命名各搞各的。
十一、负责人检查表
单号全局唯一、支付后读主库、语言包发版不动订单库、回调 VPC 策略单独。扩城复制拓扑而不是复制混乱。第二城上线前，用第一城同样 QPS 在预发压测读主库策略，确认支付成功页不会误读延迟副本，再切生产流量。
十二、多城同库时的备份策略
单库多城时，备份恢复影响面大，宜在演练环境定期做「恢复后随机抽 10 单可查」而不仅是「库能起来」。恢复 RTO 写进运维手册，值班按手册执行，避免临场翻文档。多城团队宜每季度做一次恢复演练，而不是只在签约时演示一次备份按钮。演练记录宜存档，满足部分市场合规对「可恢复性证明」的要求。演练失败项宜有工单跟踪，直到下次演练通过，而不是「知道有问题但一直拖着」。海外多城业务连续性要求往往高于国内，演练宜纳入季度固定动作，与业务扩城节奏对齐。
