永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
“实时”位置数据究竟需要什么
“实时”这个词被贴在很多位置数据产品上，作为响应速度快的简称，而速度确实是值得优化的真实指标。但对于描述世界当前状态的数据来说，这与“实时”真正应该意味着的内容完全是两回事：“实时”应该意味着答案反映的是此刻的真实情况，而不是针对一个早已编制完成、此后再未有实质更新的数据集进行的一次快速、低延迟的查询。
这种区别对 IP 地理定位来说尤其重要，因为 IP 地址段与其物理位置之间的映射会随着时间而变化，地址块会被负责管理它们的区域互联网注册机构重新分配、重新划拨或改作他用。一个针对过时映射在几毫秒内返回的查询，既快又错，而速度对纠正错误毫无帮助。真正的实时 IP 地理定位要求底层映射本身保持最新，需要有一个实时查询流程和一个会被刷新的缓存，而不是把它当作一个固定的一次性快照。
我们的 IP 地理定位正是围绕这一区别构建的：它实时运行，使用缓存来保持较低的响应时间，而不是用缓存代替数据的新鲜度；并且有一个后台重试流程，持续处理需要重新检查的数据，而不是让一个定期的 cron 任务作为保持映射最新的唯一机制。我们的目标是让缓存带来速度而不带来过时，这与一个纯粹为了避免重新计算任何东西（无论数据是否最新）而存在的缓存，是不同的设计目标。
同样的区别以另一种形式适用于时区数据。一个快速返回、但所描述的偏移量没有考虑到最近一次夏令时切换或最近一次政府规则变更的响应，在任何有意义的层面上都不是实时的，即使它在十毫秒内就返回了。这里的实时意味着底层参考数据（在这里是 IANA 时区数据库）在变化时被跟踪并应用，而不是指响应针对一张最近无人更新过的表格快速返回。
我们认为，“实时”首先应被视为关于数据时效性的声明，其次才是关于响应延迟的声明，尽管延迟是最容易衡量和展示的部分。服务商完全可以把响应时间优化到不到一秒，同时悄悄让底层数据过时好几个月，而从外部看，一个快速的错误答案和一个快速的正确答案看起来一模一样，直到下游的某个环节依赖于两者的差别。更难、更不显眼的工作，是保持数据本身的时效性。这才是真正配得上这个标签的部分，也是客户仅靠给请求计时无法验证的部分。