标准答案
- API 层限制用户和接口流量，数据库层限制连接与查询并发，消息层限制生产和消费速率，三者职责要明确。
- 请求进入队列前先检查剩余 deadline，已经没有价值的工作不要继续占用下游容量。
- 重试应由一个责任层协调，其他层返回可分类的限流或暂时失败信号。
- 用 trace 和请求 ID关联每次尝试，监控放大倍数、队列等待和最终成功率。
题目解析
API、数据库和消息层分别有自己的容量边界，但同一个请求不应在每一层都无限排队。入口要先判断用户 deadline 和业务价值，再决定是否值得占用后续资源。
重试责任要有一个明确归属层，其余层返回可分类的暂时失败、限流或确定性错误。否则一次故障可能在入口、客户端、数据库和消息消费者之间乘法放大。
用 trace、请求 ID 和尝试编号关联每一次执行，观察放大倍数、各层排队时间、最终成功率和副作用。多层保护的目标是缩短无价值工作，而不是把延迟藏得更深。
常见误区
- 误区：入口、数据库和消息层都无限排队。改正：指定唯一主要背压点，其余层快速失败或传递剩余 deadline。
- 误区：每一层都自动重试。改正：统一重试责任、预算和幂等规则，避免请求数量乘法增长。
- 误区：限流错误不区分可重试和不可重试。改正：返回明确错误类别和 Retry-After 或业务重试边界。