限流

按商户 × 桶计，滑动窗口。桶由「方法 + 路径前缀」判定。

POST /v1/deposits 拿最紧的一档，因为它是全系统唯一一个凭空产生会员余额的端点。

超了会怎样

HTTP 429
Retry-After: 60

{ "error": { "code": "rate_limited", "message": "…", "retry_after": 60 } }

按 Retry-After 退避，不要立刻重试。它给的是当前窗口的秒数。

两件要知道的事

判据是路径前缀，不是端点清单。 认不出的写请求按 orders 收，认不出的读按

reads 收 —— 所以我方新增一个端点时它天然有闸。清单式的做法要求每加一个端点

记得补一行，而漏掉的那一条不报错，它只是没有闸。

429 是可恢复的，把它当正常路径处理。 收到 429 不代表你被封了。真正不可恢复的

是余额被凭空刷出来 —— 配额就是按这个取舍定的，宁可让正常商户偶尔退避一次。

别把我方当数据库轮询

reads 给到 1200/分钟不是让你每秒扫一遍订单表。状态变更请接 Webhook：

它带 status_version，你按版本号向前合并即可。轮询除了烧配额，还会因为

「慢响应后到」把已完成的订单打回处理中。