面向产品 API 的缓存策略

命名新鲜度契约

在选择 Redis、CDN 规则或 HTTP 头之前，决定响应可陈旧到什么程度，以及出错时会发生什么。个人资料页、库存计数、价格与权限对延迟的容忍度不同。单一全局 TTL 通常是产品错误。

用客户端可依赖的工程语言写出契约：绝对过期、事件驱动失效或显式再验证。模糊的新鲜度会制造互相争斗的重复缓存层。

缓存在受众所在之处

公开内容受益于边缘缓存。按用户的仪表盘常需以身份与租户为键的应用级缓存。昂贵的聚合计算可能需要物化，而非短命键值条目。

避免缓存未授权响应或嵌入密钥的响应。缓存键必须包含每个改变含义的维度：语言环境、套餐、功能开关与表示版本。

• 在过期时防止惊群
• 优先幂等的重计算路径
• 同时观察命中率与错误数据事故
• 在有意义的领域事件上失效

失效是难点

基于时间的过期简单，对协作数据往往错误。基于事件的失效精确，却容易漏掉某个生产者。许多系统对关键实体结合适中 TTL 与写路径上的显式清除。

设计删除与更新流，发出缓存所需信号。若写方不知读方缓存，陈旧数据会成为反复事故主题。

衡量用户可见结果

高命中率伴随关于过时信息的支持工单上升，不是胜利。一并跟踪延迟百分位、源站负载与正确性投诉。缓存策略应让产品同时感觉快速与可信。

最好的缓存是看不见的：用户及时得到答案，源站保持平静，工程师能精确解释数据何时允许滞后。