刚结束 Square 的 onsite，面的是一个 senior SWE 职位（他们内部大概叫 L5，不过对外不一定用这个标签）。一共四轮。我想专门写一下 system design 那轮，因为它跟我准备的内容差别最大。
题目跟支付相关。但不是「design Twitter（设计 Twitter）」或者「design YouTube（设计 YouTube）」这种，他们给了一个很贴近 Square 真实业务的场景。大概是：设计一个能大规模处理争议解决的系统，merchant 和 buyer 都会和同一条记录交互。我就不贴原题了，但确实（heh）就是他们的核心领域。
他们看重的点： 先数据模型。 我还没开始讲服务或 API，他们就让我先定义核心实体。Dispute、transaction、party、state machine。他们对我最初的 schema 有 push back：「what happens when a dispute has multiple sub-claims?（争议里有多个子 claim 会怎样？）」这个问题问得很好，我只能现场改。 要 state machine，不只是 CRUD。 Dispute 会在不同状态间流转。他们希望我考虑 idempotency、重试，以及给银行发 webhook 的时候如果中途失败怎么办。这是 fintech，这些东西很关键。 Eventual consistency 的权衡。 我一开始偏向强一致模型（Postgres、单写入者），他们追问：「at what scale does this break?（到什么规模会撑不住？）」然后我们讨论了 event sourcing 作为替代方案。我觉得没有唯一正确答案，他们想听我怎么推理。
不太重要的点：我几乎没怎么聊 load balancer 配置或缓存层。他们也不太在意我的 CDN 策略。
45 分钟，一个面试官，全程很聊天式。完全不刁钻。我本来以为会是那种偏 Leetcode 的 system design：画方框、给服务起名字。结果更像是「让我看看你是不是真懂支付系统」的讨论。
准备建议：补一下 state machine、金融系统里的 idempotency，以及在 payments 语境下的 CAP 定理。如果你做过任何分布式事务或 webhook 相关的东西，把这些例子拿出来讲。
整个 loop 是两轮 coding + system design + behavioral。我的结果大概 8 个工作日出来。