CAP 定理由 Eric Brewer 提出，指出在分布式数据库系统中，您只能同时保证三个属性中的两个：一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）。一致性意味着每次读取都接收到最新的写入或错误。可用性确保每个请求都收到非错误响应，即使某些节点处于离线状态。分区容错性意味着系统在发生网络故障时仍能继续运行，这些故障会将节点分成孤立的组。该定理强调了一个根本性的权衡：当发生网络分区（例如，节点失去连接）时，系统必须在保持一致性或可用性之间做出选择。这种选择决定了数据库如何处理故障和数据同步。
在实践中，分布式数据库优先考虑一致性 + 分区容错性 (CP) 或可用性 + 分区容错性 (AP)。例如，像 MongoDB 这样的 CP 系统（配置为强一致性时）确保所有节点在分区期间都具有相同的数据，但如果节点无法通信，则可能会暂时不可用。相反，像 Apache Cassandra 这样的 AP 系统在分区期间保持可用，即使某些节点已断开连接，也允许读取和写入，但可能会返回过时的数据，直到分区解决。纯粹的一致性 + 可用性 (CA) 系统很少见，因为网络分区在分布式环境中是不可避免的，因此分区容错性实际上是必需的。大多数数据库都专注于 CP 或 AP，并在分区期间动态调整其行为。
真实世界的系统通常通过设计选择来平衡 CAP 的权衡。例如，许多 AP 数据库使用最终一致性，其中数据在恢复通信后收敛到一致状态。 Cassandra 允许开发人员为每个查询调整一致性级别（例如，要求来自大多数节点的响应以进行关键写入）。同样，像 Google Spanner 这样的 CP 系统使用同步时钟和共识算法来最大限度地减少停机时间，同时保持一致性。该选择取决于用例：金融系统优先考虑一致性以防止不正确的余额，而社交媒体平台可能倾向于可用性以确保用户即使在中断期间也可以发帖。在选择数据库时，开发人员必须评估其应用程序对陈旧数据、停机时间和恢复复杂性的容忍度。