0. 一个接口设计的取舍：用户没订阅，算不算错误
做这个接口的时候遇到的第一个问题不是技术问题，是语义问题。
Engineering Notes
孟斌的小站
技术博客与学习记录
0. 问题：缓存怎么知道该失效了
第 12 篇讲了三层缓存，但留了一个尾巴没讲：缓存什么时候该失效。
0. 一个数字让我决定加缓存
第 1 篇里算过一笔账：relay-gateway 处理一个请求，要打四次下游 gRPC——identity 鉴权、channel 选路、billing 预扣、billing 结算，外加写日志。
0. 一个编号，两种假设
我第一版迁移就是一个编号序列：001_xxx.sql、002_xxx.sql……每个文件一个号，跑的时候按号排序。
0. 一个看起来很简单的问题，答案不简单
用户买了一个月的套餐，付了 20 块。用了 10 天，要求退款。
0. 一个反直觉的判断：不是所有接口都该被适配
做网关的时候我一开始的想法是"给每个上游接口写一个适配器"。
0. 一个把我绕进去的概念冲突
做订阅功能的时候，我脑子里只有一个"额度"概念：用户买了套餐，每个月能用 20 美元，超过就停。
0. 先说结论：只有四家需要真正写代码
接上游 provider 这件事，我一开始以为是"一家一个适配器"。写了才发现不是：三十多个渠道类型里，真正需要单独写协议转换逻辑的只有四家，其余二十多家全是同一个适配器的不同配置。
0. 一个第一次写 OAuth 刷新很容易漏掉的事
我第一版的 token 刷新逻辑大概是这样的：
0. 一个迟早要面对的问题
订阅账号会有各种"暂时不能用"的情况：被上游限流了、额度用完了、凭据过期了、上游在抖动。这些状态都要有退出机制——总不能因为一次 429 就永远不再用这个账号。