你的拆分架构并非主动选择，而是日积月累形成的
内容提要
许多团队的“拆分架构”（数据同时存于多个数据库）并非主动选择，而是由为报表加只读副本、为实验单独建库、并购后同步数据等临时方案累积而成。其隐性代价是：副本非权威数据源、存在延迟、无人负责正确性，最终导致数据对不上。建议每次新增系统前明确记录原因、权威来源和延迟容忍度，并先评估主数据库能否直接满足需求。
延伸解读
“能用就行”是架构失控的信号
文章指出，当团队用“它今天还能跑”来为现有拆分辩护，而不是解释当初为何这样设计时，往往说明这个拆分是累积出来的，而非主动选择。主动决策会伴随理由，累积的拆分则只剩“还没坏”这一条。读者可以留意团队讨论中是否频繁出现这类说法，作为识别隐性架构债务的线索。
副本的代价与管道质量无关
即使数据管道零维护、从不故障，第二份副本仍然不是权威数据源，查询时也不保证最新。文章强调，异步更新的副本无法看到主库刚提交的数据，事务保证不跨系统。因此，拆分架构的隐性成本在于：没人指定哪份是真相、可容忍延迟是多少、谁负责保持正确，而非管道本身的好坏。
新增系统前先回答三个问题
文章建议，在决定把数据放到“自己的地方”之前，先写下三件事：为什么需要这个系统、哪份数据是权威来源、可接受的延迟是多少。如果填不出来，说明还没准备好新增系统。同时应先问更便宜的问题：主数据库能否直接满足需求？若能，就不必引入副本，也省去后续治理成本。
拆分并非总是错误，但应是有意选择
文章承认，对历史数据做批量分析、或设计好的区域复制等场景，独立系统可以是合理选择。关键在于：有人权衡过、写下了原因、知道放弃了什么，并且明确权威来源和延迟容忍度。读者应区分“主动选择的拆分”与“累积形成的拆分”，对后者逐一追问：今天是否还会这样选？
Q&A
什么是拆分架构？为什么很多团队会不知不觉地采用它？
拆分架构是指应用数据存放在多个数据库中，通常用Postgres处理事务，另有一个存储保存副本用于分析或特定功能。很多团队并非主动选择，而是由一系列看似合理的临时方案累积而成，比如为报表加只读副本、为实验单独建库、并购后同步数据等，每一步都合理，但最终形成了拆分。
拆分架构有哪些隐性成本？即使数据管道很完美也无法避免吗？
隐性成本包括：副本不是权威数据源，异步更新无法保证查询时是最新的；事务保证不跨系统，副本看不到主库刚提交的数据；没人决定哪个副本是真相，各团队信任自己查询的副本；没人规定可接受的延迟，延迟是多少就是多少；没人负责保持数据正确。即使管道完美，副本仍然是下游数据，成本依然存在。
如何判断团队已经陷入了非主动选择的拆分架构？
一个明显的信号是团队用“目前还能用”来为现有拆分辩护，而不是用设计理由。没有人会说“保留两份订单数据是正确设计，原因是……”，他们只是主张别动它。主动做出的决策会用当初的理由来辩护，而累积形成的拆分没有理由可讲，只能说还没出问题。
在什么情况下单独使用一个数据库系统是合理的？
两种常见合理场景：一是对历史数据进行批量分析，结果不需要反映最近几分钟的变化，副本延迟几小时也无所谓，且能把工作负载从主库移开；二是复制作为主动决策，例如边缘或区域数据库向中心数据库同步数据，此时一方是明确的权威源，延迟是约定好的数字，并且有人负责保持正确。
在新增系统前应该记录哪些关键信息？
当有人说“把它放到单独的地方”时，应写下三件事：新增系统的原因、权威数据来源、可接受的延迟容忍度。如果无法填写这些信息，说明还没准备好添加系统。在此之前，先问更便宜的问题：主数据库能否直接满足需求？如果能，就没有副本需要治理。
对于已经存在的拆分，团队应该如何处理？
逐一审视现有拆分，问自己：如果今天知道它的成本，还会选择它吗？有些会回答“是”，保留并写下原因；其余就是累积形成的拆分。结束非主动拆分的方式是让下一次决策有意识，从了解主数据库能做什么开始。如果分析是引入第二副本的原因，先检查主库是否已能胜任。
