上个月刚走完 Snap L5 的完整流程，system design 这轮说实话是最有意思的。趁还新鲜写一下。
形式是 45 分钟，两位面试官。一个是 Stories infra 团队的 senior SWE，另一个来自 messaging 方向。他们先给了我大概 5 分钟铺垫，然后就进 prompt。
实际的 prompt：Design a real-time story view counter for a platform that handles hundreds of millions of views per day.（为一个每天有数亿次浏览的平台设计一个实时 story 浏览计数器。）经典分布式系统题。
他们真正考的不是我会不会背 CAP theorem，而是我能不能把 tradeoff 说清楚。我说会用 eventual consistency 加 write-behind cache 时，infra 面试官追问：如果我们希望创作者感知到的计数是实时的怎么办？于是我们聊到混合方案，比如在 Redis 里维护 hot-path counter，再定期同步到 Postgres。他们看起来是真的对讨论过程有兴趣，而不是只看答案。
聊到的点包括：高基数 key space 的分片策略、viral snaps 引发的 thundering herd 怎么处理、cache 层挂了如何优雅降级。有位面试官在对话中很随口提到 Snap 在用 Kafka，我当成一个暗示。
我没有遇到「设计整个 messaging system」那种题。据我听说那是两年前更常见。2025-2026 的流程似乎更聚焦，围绕某个具体子系统。
时间分配：他们希望大概 10 分钟需求，15 分钟高层设计，20 分钟 deep dive。我 deep dive 讲超了（我的锅），最后不得不赶 failure modes。别学我。
背景：我做 backend，大概 7 年分布式系统经验，之前在一家 fintech。我用 Grokking 准备，也做了几次 mock。Snap 的面试官很友好，没有坑题，但你开了某条线他们就会往下追，所以别随便夸口自己很懂。