刚结束 Stripe 的 senior SWE role 全套 loop，趁还新鲜写一下，因为我准备的时候几乎找不到有用信息。
Stripe 的 system design 轮是 60 分钟。一个面试官，一个题目。我的大概是：设计一个 payment reconciliation 系统，能高吞吐摄取交易数据，识别商户上报的数据和 Stripe 自己账本里显示的数据之间的不一致，并把差异暴露给内部 ops 团队。
注意这个题是什么：一个真实的 Stripe 问题。不是「design Twitter（设计 Twitter）」或者「design Uber.（设计 Uber。）」。他们希望你围绕 fintech 领域来设计。如果你从没认真想过幂等、exactly-once delivery、分布式事务、账本正确性，这一轮你会明显吃力。
他们实际在乎的点，大概按重要性递减：
正确性优先于规模。 我一上来就讲 Kafka 分区怎么 shard，然后他们把我拉慢了。「Walk us through how you guarantee the reconciliation is correct before we talk about 10x scale.（在我们讨论 10 倍扩展之前，带我们过一遍你如何保证对账是正确的。）」（在保证对账正确之前，先别谈 10 倍扩展，带我们过一遍你怎么保证对账正确。）这就是信号。先把数据模型做对。
故障模式。 如果你的对账任务跑到一半崩了会怎样？部分状态会长什么样？怎么安全重启？这就是 L5 和 L4 的分水岭。Junior 候选人讲的是 happy path。Staff 候选人讲的是哪里会坏。
把取舍说出来。 我提了 event-sourcing 方案，他们让我和更简单的 diff-table 方案对比。他们不是在钓“标准答案”，而是想听我对一致性、运维复杂度、以及一年后团队怎么 debug 的推理过程。
我没有拿到最终 offer（大概率是定级不匹配，可能会给 L4），但这轮 design 是我近几年遇到最有含金量的一轮。没用白板，就在 Google Meet 的共享文档里。
给准备的人一个建议：读 Stripe 的 engineering blog。他们写过 data pipeline、幂等 key、分布式系统相关的文章。面试官显然读过这些文章，也可能默认你也看过。
时间分配：5-10 分钟 scope，30-35 分钟设计，10-15 分钟深挖一个组件，最后 5 分钟提问。