接单系统异构：先高效写一份原始数据，再异步拆分到各张业务表

接单是一个天生要求高吞吐、低延迟的写路径，但订单本身在传统数据模型下往往需要拆解写入多张不同的表（订单明细表、促销明细表、优惠券表等），如果按传统做法，每次提交订单都要同步写入这么多张表，写入压力和延迟都会成为整个下单链路的瓶颈。京东的解法是把”接收订单”和”把订单拆解落库”这两件事在时间上彻底分开：接单时只需要高效地把这次提交的完整数据整体写下来（一次提交只写一份数据，而不是拆开写多张表），这一步做到极致简单高效；写完之后，再通过一个状态机驱动的管道服务，异步地把这份原始数据拆分成订单中心需要的各个细分数据结构，分别落到订单中心各自的存储里，同时再异构出一份专门服务于其他查询场景的订单存储。这样一来，真正对延迟敏感、并发压力最大的”接单”这一步被大幅简化，只承担”快速可靠地记下这次提交”这一个职责；而”如何把这份数据整理成各个下游系统需要的形态”这件更复杂、涉及多张表的工作，被转移到了对延迟不敏感的异步流程里完成，两边各自的系统应对峰值的能力都因此得到了提升。这个案例给出了一条应对”高并发写入+复杂数据结构落地”矛盾的通用思路：当一次业务操作既要求极致的写入性能、又需要产出复杂的多份衍生数据时，不要试图让同一次同步写操作既快又全，而应该把”快速记录这次操作发生了什么”和”把这次操作转化成各个下游需要的具体数据形态”拆成两个独立的阶段，前者追求极致的吞吐和低延迟，后者放到异步链路里从容处理复杂逻辑。