在国内做技术的时候，网络延迟通常不是一个需要认真对待的问题。但当你的服务需要同时部署在新加坡、法兰克福和弗吉尼亚时，物理距离带来的延迟变成了一个硬约束。中国到欧洲的网络往返时间（RTT）在 200-300ms，这意味着如果一个请求链路上有四次跨区域调用，光是网络延迟就超过了一秒。
我们最初的架构没有充分考虑这一点，很多服务间调用是同步的、串行的。全球化部署后，这些原本在同机房内毫秒级完成的调用变成了性能杀手。重新设计调用链路、引入异步化和数据预取，花了将近半年时间。
GDPR、CCPA、PIPL——每个地区都有自己的数据保护法规，而且这些法规还在持续演进。合规不仅仅是法务部门的事情，它会直接影响技术架构。最典型的要求是数据本地化——某些类别的用户数据不能离开特定区域。
这对存储和计算架构提出了严格约束。你不能简单地把所有数据同步到一个中心化的数据库，而是需要按区域分片，同时保证跨区域的业务逻辑仍然能正确运行。我们为此构建了一套数据分类和路由系统，根据数据的敏感级别自动决定存储和传输策略。
分布式系统中的一致性本来就是难题，跨区域部署把难度又提升了一个量级。CAP 定理告诉我们不能同时拥有一致性和可用性，在跨区域场景下，我们几乎总是选择可用性，然后在业务层面接受最终一致性。
但「最终一致」不是万能的遮羞布。对于库存、支付这类场景，数据不一致可能意味着资金损失。我们对不同的业务场景定义了不同的一致性级别，关键路径使用强一致性（接受更高延迟），非关键路径使用最终一致性（优先保证可用性）。
全球化场景下 CDN 的价值被放大了。静态资源通过 CDN 分发到全球边缘节点，用户就近访问，延迟可以控制在 50ms 以内。我们还在探索边缘计算的可能性——把部分动态逻辑下沉到边缘节点执行，进一步减少用户感知到的延迟。但边缘计算的调试和运维复杂度不低，目前还处于小规模试点阶段。