OpenAI 系统设计题为什么总偏基础设施？四个高频题的拆解框架

最近整理公开的系统设计面经时发现一个规律：OpenAI 的 design 题特别偏基础设施，很少考“设计一个 Instagram”这种产品题。把四个反复出现的题型拆了一下，分享我的准备框架，也想和大家讨论标准解法之外的取舍。

先声明：以下是公开资料的整理和我自己的备考框架，不是个人面经。

## 1. Webhook 投递系统

我拆的顺序：事件产生 → 入队 → 投递 worker → 失败重试（指数退避）→ 死信队列。
面试官最爱追问的点：
- 怎么保证不重复投递？（投递方 idempotency key + 接收方去重）
- 某个租户的 endpoint 一直挂，会不会拖垮其他租户？（按租户隔离+限流）
- 顺序性要不要保证？多数场景其实只要最终送达，硬保序代价很大，要敢说不保序的理由。

## 2. Payment System

框架：下单/授权 → 状态机（pending / authorized / captured / refunded）→ 对账。
关键不是画出多少框，而是状态机和幂等：同一笔支付请求重试十次，只能扣一次钱。还有和第三方渠道的对账、部分退款、货币精度这些细节，能主动提出来很加分。

## 3. 推理服务 / GPU 调度

这是最近出现频率明显变高的一类：模型请求怎么排队、GPU 怎么分配、怎么扩缩容。
我的准备角度：
- 请求特征：延迟敏感 vs 吞吐优先要分开对待，大模型和小模型别混在一个池子里调度
- 资源：显存是硬约束，一台机器能同时装几个模型要算清楚
- 降级：流量尖峰时怎么办——排队、限流、还是降到小模型，要有取舍的说法

## 4. Power Grid / 电网调度类

这类一开始很陌生，后来发现本质是“资源调度+状态监控”的变体：发电/用电的实时平衡、设备拓扑、故障时怎么切换。和 GPU 调度其实是同一种思维：稀缺资源、实时约束、故障隔离。准备过调度类题目的话迁移很快。

## 我的体会

这四个题表面上差很远，内核都是三件事：**状态怎么管理、失败怎么处理、资源怎么隔离**。面试官追问也基本围绕这三点，所以我准备的时候不再背完整答案，而是每个题都把这三问先想透。

大家面过类似题目的话，面试官最爱在哪一步深挖？欢迎讨论，我把有价值的点更新到主楼。