Companies like Google, Apple, Microsoft offer multiple services (Drive, Photos, Docs, Mail, etc.) under a single storage quota. When a user purchases a 100GB plan, all services consume from the same quota bucket.

系统结构大致如下：

• 多个 Applications
• 每个 Application 下有多个 Services（S1, S2, …）
• 所有服务共享一个 Quota Service
• Client 的所有写入请求都会经过这些服务链路最终影响 quota

Design a quota service that supports multiple applications and services consuming from the same user quota bucket.

面试官给的背景很简单：用户买了 100GB，Drive、Photos、Docs、Mail 全都在用同一个 quota。系统里有多个 Application，每个下面有不同的 Service，所有写入最终都会影响一个统一的 Quota Service。

他没有铺垫，直接让设计。

候选人先把问题说透，这是一个多服务并发写入同一资源池的计量系统。核心不是存储，而是如何保证“不会超额”。

模型被压成三个数：total、used、reserved。任何写入都不能直接修改 used，必须先走 reserve，占一段额度，再去写数据，成功之后再 commit，把 reserved 转成 used，失败就 release。

面试官追问并发。

回答很直接，这里不能靠应用层判断剩余空间，否则多个服务同时写一定会穿透。Quota Service 必须做原子扣减，让“检查 + 占用”变成一个不可分割的操作，它是唯一的真相来源，所有服务都只能调用它。

接着问性能。

如果所有请求都打到 Quota Service，一定扛不住。解决方式是在 service 侧做一层预分配，小额度本地消耗，用完再批量申请，这样远程调用次数会明显下降。

面试官继续压异常。

候选人给了一个典型场景：reserve 成功，服务挂了，这部分额度会卡住。处理方式是给 reservation 加 TTL，超时自动回收。还有一种情况是数据写成功但 commit 丢了，这时候需要后台对账，把实际存储和 quota 做校正。

最后面试官问为什么不能让各个服务自己管 quota。

回答很短，多个服务各自计数，无法保证全局一致，一定会超额。

这题到这里基本结束。

csoahelp 做的就是这种场景里的实时辅助，题目刚读完就能给出完整思路，现场不用卡壳。

我们也有代面试，面试辅助，OA代写等服务助您早日上岸~