我相信你已经看到了这一点，“这取决于情况”。
这取决于一切。与部门 A 共享客户数据的解决方案可能与与部门 B 共享客户数据的解决方案完全不同。
多年来我最喜欢的概念是“最终一致性”的概念。该术语来自亚马逊谈论分布式系统。
前提是，虽然分布式企业中的数据状态现在可能不完全一致，但“最终”会是完全一致的。
例如，当系统 A 上的客户记录更新时，系统 B 的客户数据现在已过时且不匹配。但是，“最终”，来自 A 的记录将通过某种过程发送到 B。因此，最终，两个实例将匹配。
当您使用单个系统时，您没有“EC”，而是具有即时更新、单个“事实来源”，以及通常处理竞争条件和冲突的锁定机制。
您的操作处理“EC”数据的能力越强，分离这些系统就越容易。一个简单的例子是销售使用的数据仓库。他们使用 DW 运行每日报告，但直到凌晨才运行报告，并且总是查看“昨天”（或更早）的数据。因此数据仓库并不需要实时与日常运营系统完全一致。流程在营业时间结束时运行并在大型单一更新操作中集中移动这些天的事务和活动是完全可以接受的。
你可以看到这个需求如何解决很多问题。事务数据不存在争用，不用担心某些报告数据会在累积统计数据的过程中发生变化，因为报告对实时数据库进行了两次单独的查询。白天不需要因为高细节的喋喋不休而占用网络和CPU处理等。
这是 EC 的一个极端的、简化的、非常粗略的例子。
但考虑一下像谷歌这样的大型系统。作为搜索的消费者，我们不知道谷歌收集的搜索结果何时或需要多长时间才能出现在搜索页面上。 1毫秒？ 1秒？ 10秒？ 10小时？很容易想象，如果您访问谷歌的西海岸服务器，您很可能会得到与访问其东海岸服务器不同的搜索结果。这两个实例在任何时候都不完全一致。但从很大程度上来说，它们大多是一致的。对于他们的用例来说，他们的消费者并没有真正受到滞后和延迟的影响。
考虑电子邮件。 A 想要向 B 发送消息，但在此过程中，消息要经过系统 C、D 和 E。每个系统都接受该消息，并对其承担全部责任，然后将其交给另一个系统。发件人看到电子邮件正在发送。接收者并不会真正错过它，因为他们不一定知道它的到来。因此，该消息在系统中传输需要很长的时间，而没有人知道或关心它的速度有多快。
另一方面，A可能正在和B通电话。“我刚刚发了，你收到了吗？现在？现在？现在收到吗？”
因此，存在某种潜在的、隐含的绩效和响应水平。最后，“最终”，A 的发件箱与 B 的收件箱匹配。
这些延迟、对陈旧数据的接受（无论是一天前的数据还是 1-5 秒前的数据）是控制系统最终耦合的因素。此要求越宽松，耦合就越松散，您在设计方面的灵活性就越大。
对于 CPU 的核心来说也是如此。在同一系统上运行的现代多核、多线程应用程序可以对“相同”数据有不同的视图，仅过时微秒。如果您的代码可以正确处理可能彼此不一致的数据，那么快乐的一天，它就会顺利进行。如果不是，您需要特别注意确保数据完全一致，使用易失性内存限定或锁定结构等技术。所有这些都以它们的方式降低了性能。
所以，这是基本的考虑。所有其他决定都从这里开始。回答这个问题可以告诉您如何跨机器对应用程序进行分区、共享哪些资源以及如何共享它们。有哪些协议和技术可用于移动数据，以及执行传输的处理成本是多少。复制、负载均衡、数据共享等等都是基于这个概念。
编辑，回应第一条评论。
正确，完全正确。这里的博弈，例如，如果B不能改变客户数据，那么改变客户数据有什么危害呢？你能“冒”它在短时间内过时的风险吗？也许您的客户数据输入速度足够慢，您可以立即将其从 A 复制到 B。假设零钱被放在一个队列中，由于交易量小，很容易被提取（
现在头脑真的开始旋转了。在那一秒的“滞后”期间会发生什么，最糟糕的情况是什么。你能围绕它进行设计吗？如果您可以设计 1 秒左右的延迟，那么您也许可以设计 5 秒、1 米甚至更长的延迟。您在 B 上实际使用了多少客户数据？也许B是一个旨在促进库存订单拣选的系统。很难想象还有什么比简单的客户 ID 和名称更重要的了。只是在组装订单时粗略地识别订单的对象。
拣货系统不一定需要在拣货过程结束之前打印出所有客户信息，到那时订单可能已经转移到另一个可能更最新的系统，尤其是运输信息，因此最终，拣货系统几乎不需要任何客户数据。事实上，您可以在提货订单中嵌入和非规范化客户信息，因此不需要或期望稍后进行同步。只要客户 ID 正确（无论如何都不会改变）和名称（很少改变，不值得讨论），这就是您需要的唯一真实参考，并且您的所有提货单在当时都完全准确创建。
诀窍在于心态，即打破系统并专注于任务所需的基本数据。您不需要的数据不需要复制或同步。人们对非规范化和数据缩减之类的事情感到恼火，尤其是当他们来自关系数据建模领域时。并且有充分的理由，应该谨慎考虑。但一旦你采用分布式，你就隐式地非规范化了。哎呀，你现在正在批量复制它。所以，你最好在这方面变得更聪明。
所有这些都可以通过可靠的程序和对工作流程的透彻理解来缓解。识别风险并制定处理风险的政策和程序。
但困难的部分是从一开始就打破中央数据库的链条，并告诉人们，当你拥有一个单一的、中央的、完美的信息存储时，他们不能像他们所期望的那样“拥有一切”。
