CAP 定理，也称为 Brewer 定理，解释了分布式系统在处理网络分区时面临的权衡。它指出，分布式数据库最多只能提供三个保证中的两个：一致性（所有节点在同一时间看到相同的数据）、可用性（每个请求都能收到响应）和分区容错性（系统在网络故障时仍能继续运行）。实际上，在分布式系统中，分区容错性是不可避免的，因此在发生分区时，真正的选择是一致性或可用性。例如，如果发生网络分裂，一个优先考虑一致性 (CP) 的系统可能会拒绝请求以避免提供过时数据，而一个偏向可用性 (AP) 的系统可能会返回潜在的过时数据但保持响应。
文档数据库，如 MongoDB 或 CouchDB，根据其设计实现了 CAP 权衡。例如，MongoDB 通常被归类为 CP 系统。默认情况下，它优先考虑一致性和分区容错性：在网络分区期间，如果 MongoDB 主节点失去与副本集成员的联系，它将停止接受写入，确保数据保持一致，但在分区解决之前牺牲可用性。相比之下，CouchDB 倾向于 AP。它允许在分区期间对任何节点进行写入，接受临时不一致（例如，冲突的文档版本）以保持可用性。这些冲突稍后必须通过手动或应用程序逻辑解决。另一个例子是 Amazon DynamoDB，它提供可调一致性：开发者可以为关键操作选择强一致性（类似 CP），或为较低延迟选择最终一致性（类似 AP）。
在使用文档数据库时，开发者必须根据应用程序需求进行选择。对于像财务账本这样一致性至关重要的系统，CP 导向的数据库可确保数据完整性，但在分区期间存在停机风险。对于像社交媒体 feed 这样的高流量应用程序，AP 数据库优先考虑正常运行时间，接受最终一致性。现代文档数据库通常提供工具来缓解这些权衡。例如，MongoDB 的可重试写入可处理瞬时故障，而 CouchDB 的冲突解决机制有助于协调差异数据。理解 CAP 有助于开发者预测数据库在压力下的行为，并设计回退策略，如缓存或幂等操作，以平衡用户体验和数据可靠性。