做跨境电商 的代购系统，最刺激的不是平时，是大促。去年一波活动订单十分钟翻十倍，监控一路飘红。好在没有崩，复盘下来靠的不是堆机器，而是几处提前做对的架构选择。

第一，接单和算账分离。客户下单页只做轻量校验，重活——拉货源API、算多币种 总价、生成采购单——全丢消息队列异步。多语言 商城页的静态资源也走 CDN 缓存，洪峰下连源站都不用碰。前端响应始终快，用户毫无感知。同步阻塞是洪峰下最大的杀手。

第二，读多写少的地方加缓存。商品详情、汇率、库存这些高频读低频变的数据，我全放 Redis。1688代采 的商品页每秒几千次访问，直接打库早炸了。缓存把数据库压力削掉一大半，这也是 SaaS系统 标配套路。

第三，限流和熔断。异常订单、刷单请求在网关层就拦掉，不进核心链路。taocarts 这类把限流和队列预制好的系统，让我没在半夜手忙脚乱改代码，只调了几个阈值就稳住。工具接住复杂，我把注意力放在监控大盘上。

第四，履约别掉链。订单暴增后，海外仓 的本地发货和集运系统 的合包预报跟不上，前面接住的单全变差评。所以异步任务里履约环节单独拆队列、单独扩容，保证「接得住单、发得出货」是闭环。

这场仗打完，我更确信：洪峰不可怕，可怕的是链路没分层。把各段拆开各管各的扩容，系统才扛造。普通人做跨境，与其自己调架构，不如先用成熟方案把这几层接住，把精力放在选品上。架构清晰，反向海淘 这门生意半夜才不会被叫醒，也才敢接更大的量。

这套分层思路，说白了就是给跨境电商平台 的每个环节留好缓冲。接单快、算账稳、履约跟得上，三者解耦，任何一段出问题都不拖累整体。普通人做跨境，先把这几层想清楚，比追新潮架构实在得多，真到大促那天，你才会感谢当初把链路拆明白的自己。架构这件小事，关键时刻就是生死线，别等崩了才想起分层这回事。