我之前在别处发过一个关于 full loop 的高层总结，但大家问最多的是 system design 这轮，所以想专门展开讲。
背景：我面的是 Atlanta 的 ground operations platform 方向的 principal/senior SWE 岗。内部定级大概是 L5-equivalent，不过 UPS 对外并不会正式用数字 level。
形式。 一个面试官，50 分钟。没有共享白板工具。我们用 Google Meet，我自己开了个 Miro board 然后 screen share。他们什么都没提供。建议你提前准备好自己的画图工具。
题目。 “Design a real-time package status system that can handle peak volume during the holiday season.” 不是逐字，但差不多。很经典的物流题，也确实很 UPS。
他们关心的是： 我会怎么处理 ingestion layer（高峰期每秒数百万 scan events） cache 放哪里，为什么 package 的状态机怎么建模（sorted、in-transit、out-for-delivery、delivered、exception） 两个 scan events 乱序到达怎么办 面向消费者的读路径 vs 内部读路径，是否应该不同
他们没有深入抠数据库 schema 设计。更多是在追问 async messaging layer 和容错。
加分点。 把 tradeoffs 讲清楚。我提 Kafka 做 ingestion，他们问为什么不是 SQS。我给了关于 ordering guarantees 和 consumer group 灵活性的真实理由，不只是“Kakfa 很常用”。他们也喜欢我量化规模：估算高峰日 30M packages 在途，每个包每天 10-15 次 scan event，然后算出大概的 QPS。
追问最深的点。 异常处理。当我们聊到“如果一个 scan 和上一个已知状态冲突，系统怎么做”时，面试官明显更来劲。这显然是他们真实会遇到的问题。
准备建议。 看看 event-driven architectures。不是因为你要把 Kafka 背到滚瓜烂熟，而是因为 UPS 的整个运营本质上就是一个分布式事件流。有这个 mental model 会很有帮助。