先回答一个很土的问题：流量上来，哪块先垮

去年有个做家居跨境的老板找我，说大促当天下午三点，后台订单数卡在 1.2 万单不动了。技术一查，数据库连接池满了。修了两个小时，流量没了，还多卖了 300 多单，客服电话从下午响到晚上。

这种事见得太多了。电商平台的系统架构，不是画几张微服务的图就完事。它得回答一个很土的问题：流量上来的时候，哪一块先垮，你打算怎么扛。

一、系统到底分成哪几块

模块 干什么 一般怎么选
前台商品与购物车 商品详情、SKU 选择、加购、下单页 自己写，跟业务强绑定
接入层、网关 限流、鉴权、灰度 用现成组件，别自己造
订单中心 下单、拆单、状态流转 必须自己写，最核心
库存中心 扣减、回滚、多仓分配 必须自己写，别外包
支付中心 渠道对接、回调、退款 自己写薄薄一层，渠道用官方 SDK
履约、仓储 拣货、发货、物流回传 国内对接 ERP，跨境自己搭
会员与营销 等级、优惠券、满减 前期能买就买
数据与对账 报表、对账文件、清结算 自己写，财务要认账

这张表的意思是：订单、库存、支付、对账这四块管着钱和货，不要偷懒。其他的能买就买。

二、库存和订单，坑最多

  • 扣库存的时机。是下单时扣，还是支付时扣？下单就扣，能防超卖，但会占库存；支付才扣，体验好，但容易超卖。跨境多仓，建议改成：下单预占，支付后确认，超时后释放，预占时间设 15 到 30 分钟。
  • 幂等。用户手抖点两次，或者网络重试，同一个订单号会进来两次。订单创建、支付回调、发货通知，全都要做幂等。别拿时间戳当唯一键，并发下会重复。
  • 订单状态机。待支付、已支付、待发货、已发货、已签收、退款中、已关闭。每个状态由谁修改、能改成什么，都要写死在代码里。不要为了省事，让运营在后台随便拖，否则出了问题根本对不上账。
  • 分布式事务。不要一上来就上 Seata、TCC。订单和库存不在一个库，用本地消息表加定时对账兜底，够用。真出了偏差，财务对账也能找回来。

三、支付和跨境，是另一个坑区

  • 汇率。下单时记录汇率快照，不要等支付成功再按当时汇率算，客户会跟你吵。
  • 回调重复。Stripe、PayPal 的回调都可能重复推送，也可能延迟半小时。回调里只做两件事：记流水、改状态。不要在回调里跑重逻辑。
  • 对账。每个渠道每天一份对账文件，T+1 拉下来，跟自己的流水逐笔比。差一笔就查一笔。跨境清结算这笔账算不清楚，月底财务会跟你翻脸。
  • 本地支付方式。香港 FPS、新加坡 PayNow、巴西 Pix 和信用卡分期、尼日利亚的银行转账和 USSD、南非 EFT。不是接一个 Stripe 就能全球通吃。非洲很多地方网络差，页面要能在弱网下打开，下单失败要能存草稿。

四、多国多仓，履约怎么排

新加坡客户下单，从深圳发还是从马来仓发？系统得按库存、运费、时效算一遍再决定。拆单是常事：A 仓有货先发，B 仓的等两天。运费规则按国家、重量、体积、渠道算，别写死。退货流程要能回库存、回财务，跨境退货还要算关税和退运成本。

五、团队和预算，说点实在的

第一版别追微服务。2 个后端、1 个前端、1 个测试、1 个产品，3 到 4 个月能出一套能跑的单体应用，模块边界划清楚就行。日均订单到 5 万单以上，再考虑把订单、库存拆出去。预算从几十万到几百万都有，差别在支付渠道数量、多语言多币种、仓储对接和后期运维。别信「一套系统打全球」，架构是根据业务逐步调整出来的，不是买出来的。

如果现在正卡在「该买 SaaS 还是自己搭」「先做哪块」这种问题上，把你们现在的单量、目标国家和预算发过来，我们帮你过一遍。鼎汇通做过 ERP、物业系统、跨境贸易平台，也帮客户从零搭过电商中台，坑踩得不少，聊半小时可能省你三个月。