我正在寻找针对以下情况的一些一般建议。这是一些背景：
组织拥有一个 API，供多个“内部”消费应用程序使用来创建、更新和查看特定信息，这些信息是这些应用程序向最终用户提供的计算的重要组成部分，该 API 提供的数据是用户基本上代表有关其组织的事实数据（POST、PUT、GET 端点集）。同时，对于最终用户来说，重要的是他们输入的信息在应用程序中是相同的，这就是为什么中央数据库有很大的好处，因为它提供了事实来源（这就是为什么这个 API 及其数据库有多个消费者）。 这样做的好处是客户的数据始终准确，不需要最终用户在多个系统中单独维护。一个主要的缺点是，拥有这样的中央数据库会引入单点故障，并且随着越来越多的数据存储在其中而降低性能。
该组织最近决定，应该追求提高这些消费应用程序的性能，并消除对集中式数据库和 API 的过度依赖。正在讨论的一种方法是继续将数据发布到中央事实来源，但不是总是通过 GET 从中检索数据（这就是发生性能问题的地方），而是存储本地数据库，该数据库是中央事实来源的副本然后通过该 API 生成的更改事件不断更新。具体来说，信息检索（而不是发布信息）是出现这些问题的地方。
对我来说，这似乎是一个非常脆弱的解决方案，因为我们过度依赖事件来保持数据最新，如果数据集不同步，那么中心事实来源的全部价值就会丢失。此外，如果您维护自己的本地数据库，那么实际上就不再有事实来源，即使它是通过使用事件驱动方法轮询 API 来更新的。
我的问题是：是否有任何值得考虑的替代解决方案来提高这些消费应用程序的性能并消除单点故障（我猜是两个独立的问题），同时仍在使用该中央数据库？需要明确的是，数据集中仍然是该组织认为需要保留的一个主要好处......但我担心这种方法不会。感谢您的阅读！ 只是寻求架构设计方面的建议。我已经考虑过所描述方法的替代方案
最终一致性我认为这个解决方案并不脆弱，这实际上是微服务/异步架构中相当常见的方法，并且可以选择通过使用适当的消息处理来消除同步失败造成的影响。它的主要问题是你正在从所谓的强一致性切换到
，这基于问题仍然是期望的（尽管你需要确保它确实是这样，但有很多情况下它是不是）
是否有任何值得考虑的替代解决方案来提高这些消费应用程序的性能并消除单点故障数据库分片还有其他方法。如果您的数据量和/或负载无法由单个数据库实例/服务器管理（请注意，有时添加同步只读副本就足够了），您可以考虑使用
（简单来说，您将数据位于多个逻辑组中，并有一个数据库实例处理其中一个/多个）或切换到使用分布式数据库之一，这基本上试图解决您遇到的相同问题。请注意，不同的数据库为您提供有关原子性（事务）/容错性的不同保证，您需要更深入地了解它们是否满足您的需求。 了解更多：
一致性
- ：每次读取都会收到最近的写入或错误。
可用性- ：每个请求都会收到一个（非错误）响应，但不保证它包含最新的写入。
分区容错性- ：尽管节点之间的网络丢弃（或延迟）任意数量的消息，系统仍继续运行。