分布式数据库系统通过在一致性、可用性和容错性之间进行设计权衡来处理网络分区——系统部分失去连接的情况。 CAP 定理指出，在分区期间，系统可以优先考虑一致性（确保所有节点都具有相同的数据）或可用性（允许节点继续服务请求），但不能同时满足两者。例如，像 Apache Cassandra 这样的系统通过允许在可访问节点上继续写入和读取来优先考虑可用性，即使这会导致临时不一致。其他系统，如 Google Spanner，通过限制操作直到分区解决来优先考虑一致性，从而确保数据保持准确，但可能会使某些服务不可用。
为了在分区期间保持可用性，许多分布式数据库使用诸如复制和最终一致性之类的技术。 例如，DynamoDB 使用基于仲裁的系统，其中必须有大多数副本确认写入才能被认为是成功的。 如果发生分区，则较小网络段中的节点可能会暂时在降级模式下运行，接受稍后在连接恢复时进行协调的写入。 冲突解决方法（如“最后写入获胜”或应用程序定义的逻辑）有助于合并不同的数据版本。 这种方法确保系统保持响应，但要求开发人员处理应用程序逻辑中潜在的冲突或陈旧数据。
对于优先考虑一致性的系统，诸如严格仲裁或共识算法（例如，Raft 或 Paxos）之类的策略很常见。 在 MongoDB 中，副本集选举一个主节点来处理所有写入，并且在分区期间，只有多数连接段保留写入权限。 少数段中的节点变为只读，直到分区恢复。 类似地，CockroachDB 使用 Raft 共识和时间戳排序的组合来确保跨分区的线性一致性。 这些方法最大限度地减少了数据不一致，但可能会引入延迟或临时不可用。 开发人员必须根据其应用程序对延迟、数据准确性和停机的容忍度来选择策略。