为什么我缓存外部 API 数据而不是每次都调用它

Source: Dev.to

初始方法

当我第一次在项目中集成外部 API 时，我的做法很简单：

需要数据？
调用 API。

这看起来简洁且合乎逻辑——直到真实使用量到来。

最初的架构如下：

Client
↓
API Gateway
↓
External API

每一次请求都会触发：

• 一个全新的 API 调用
• 一次网络往返
• 对他人可用性的依赖

在低流量时这似乎没问题，但真实使用很快暴露出裂痕。

直接调用的问题

成本

许多 API 按请求计费。起初看起来很便宜，但一旦加入后台任务、重试和流量高峰，费用就会迅速飙升。

速率限制

一旦触发速率限制：

• 功能失效
• 错误传播
• 防御性代码遍布各处

你的系统开始受制于他人的规则。

延迟

即使是快速的外部 API 也会：

• 受网络限制
• 不可预测
• 超出你的控制范围

缓存策略

我改为以下模型，而不是按需调用外部 API：

Worker / Cron
↓
External API
↓
Database

Client
↓
API Gateway
↓
Database

外部 API 定期被调用，应用程序从数据库读取——而不是直接调用 API。

好处

• API 使用量可度量且可控。
• 数据库读取更快，也更容易优化。
• 即使 API 挂掉，系统仍可使用最近一次成功获取的数据继续工作。

真正的问题不是“数据是否最新”，而是 “它需要多新鲜？” 新鲜度是业务决策，而非本能反应。

仍然适合直接调用 API 的场景

• 实时金融交易
• 身份验证与授权
• 用户触发的操作且新鲜度至关重要