1多平台各扣各的库存，超卖只能事后道歉
库存口径不统一，缓存与事实不同步，砍单伤害口碑。
典型痛点
这个行业最常见的几件麻烦事
如果下面有两条以上与你的现状吻合，说明这套方案大概率能帮上忙。都不吻合的话，也不必勉强上系统。
2活动规则一改，客服口径与系统不一致
促销规则频繁调整且缺少留痕，客服与系统说法不一。
3退款退货对不上原单，财务靠人扒
退款与原单没有强关联，对账只能人工逐笔找。
4大促瞬间流量冲击订单系统
活动开始几秒内下单与查询集中爆发，响应变慢甚至超时。
推荐起步档
零售电商建议从第二档 · 网关版起步
档位由业务现状决定，不由销售决定。以下是用「三问定档」得出的常见起点，最终以结合你企业实际的沟通结果为准。
第二档 · 网关版
组成：Go 网关 + Odoo。大促与直播的瞬时并发集中在「人」的访问链路上。
主要用到的模块
升级是「加」，不是「换」
业务增长后按增量方式升级到更高档位：人多加网关、有设备加 IoT、有重计算加插件。已有投入不浪费，具体档位差异见 数字化底座。
上线后能得到什么
结构性的改变，而不是口号
下面描述的都是系统带来的机制变化，可以逐条验证。我们不在这里承诺任何数字——效果取决于你的基础数据与执行力度。
各平台订单汇到一处，库存按同一口径扣减不再出现各平台各扣一套导致的超卖。
订单、收款、退款与原单关联财务对账有据可依，不必人工逐笔翻找。
商品与价格改动留痕，客服与系统同源减少客服口径与系统不一致引发的纠纷。
这个行业要特别注意：促销规则与库存归属是纠纷高发区，规则变更需审批留痕。**缓存不得作为最终库存依据**——这条在架构上必须是硬约束，否则大促期间的超卖会直接变成财务与口碑损失。
常见问题
零售电商客户常问的三件事
大促扛不住怎么办？
客户端限流、排队与热点缓存由 Go 网关切承载，但下单仍回到 Odoo 核验库存。具体承载量取决于部署规格与实测结果，我们不预先承诺。
平台接口经常改，维护量大吗？
适配集中在接入层，平台改版不牵动业务核心。这是分层设计的主要收益之一。
缓存会不会导致库存不准？
设计上不允许。缓存只用于展示类查询，下单与扣减必须回到事实数据核验。这是我们的架构铁律之一。
其他行业