重复录入，每天都在消耗成本。

重试、顺序与业务层面的核对

接口在超时之后，并不总能判断对方是否已经处理过某个请求。盲目重试可能因此产生重复记账。对于写入类操作，我们会规定唯一标识如何将重复请求归并到原始请求，以及这一信息的保留时长。仅有标识还不够：结果的处理和存储方式，也必须与事务模型相匹配。

对于事件，我们还会考虑顺序和延迟送达的问题。一条取消消息可能会在下游服务处理原始订单之前就已到达。允许的状态变更和版本信息，有助于从业务角度正确处理这类情况。错误队列需要明确的责任人和受控的重启机制。对重要数据的定期核对，能够发现仅监控 HTTP 响应是否成功所无法察觉的差异。

持续演进契约，同时不让已对接的团队措手不及

API 契约除了数据类型之外，还描述了含义、错误情形和边界条件。我们会明确字段缺失、空值和显式删除，是否属于不同的操作。金额需要明确货币和四舍五入规则，时间信息需要明确的参照基准。对于大规模数据，分页、筛选方式和稳定的排序也是契约的一部分。示例请求可以让使用方对这些规则加以验证。

即使是看似只做新增的变更，如果客户端只接受已知的值，也可能引发问题。因此，我们会记录所有使用方，并根据其预期检查变更的影响。新版本会配备过渡方案，包括文档、测试途径和弃用计划。对于 Webhook，会确定来源校验方式和处理重复投递的方法。可追溯的集成记录，有助于支持团队跨多个系统追踪某一具体业务事项。

限制故障影响范围，控制合作伙伴访问权限

一个响应缓慢的目标系统，不得在所有上游服务中产生数量不受限制的等待连接。我们会根据业务流程规划超时时间、有限次数的重试以及容量上限。有些任务可以先缓存，有些则必须以易于理解的方式明确失败。当某个服务不可用时，其替代返回值不得让人误以为数据是最新或已获批准的。

针对合作伙伴和应用，访问权限会分别授予，并且可以随时撤销。仅靠限速并不能阻止未经授权的数据访问，因此还会额外检查业务层面的权限。日志的作用是让错误可被分析，同时不泄露访问凭据或完整的敏感有效载荷数据。因此，移交内容还包括凭据更新、积压告警，以及针对失败消息进行定向重新处理的流程。