Node.js 在专用API（修订API/Changes API）中存储修订历史

我们大多数人可能习惯于将修订历史存储在最终数据所在的同一数据库中。这会造成可维护性和稳定性问题：

• 修订历史是一个相当复杂的系统。如果有很多API，则需要在每个API中分别重新实现。如果发现bug，则需要在每个API中分别修复它
• 在大多数情况下，修订历史不是主要的用例，但它是数据库磁盘空间和内存使用的主要贡献者，因此我们正在用大量相对较小的数据来扩充我们的API数据库

假设我们有一个修订API，它处理修订，其他服务只存储最终状态，可能还有修订UUID

这种解决方案也有缺点：

• 获取修订历史记录需要往返到另一个服务
• 如果所谓的“修订API”遇到技术困难，则所有服务都无法使用其修订历史记录
• 保持修订历史与现实同步更加困难，因为我们可能不想仅仅因为修订API关闭而拒绝CRUD请求。例如，我们可能仍然希望让用户保存其更改。否则，我们会将影响扩展到更广泛的功能范围

在我们的案例中，修订历史记录由内部员工而不是最终客户使用。当然，应用程序应该可以无缝地为每个人工作，但我们仍然将一个不那么关键但非常需要资源的功能与一个关键功能结合起来，这必须保证非常高的正常运行时间

您对集中修订历史有何看法？这是应该不惜一切代价避免的事情，还是已经被现实世界的用例很好地证明了？我可以看到，许多大公司都有用于修订历史记录的单独API，但我不确定它们是否真的将数据存储在单独的数据库中，或者只是将修订API用作网关服务