Distributed databases advertise different guarantees, and the reasons for those differences trace back to a specific, formally proven result: the CAP theorem. Understanding what it actually proves — and what it doesn’t — clarifies why “strongly consistent and always available” isn’t a real option for a distributed system, no matter how well engineered.

The three properties

The CAP theorem, named for Consistency, Availability, and Partition tolerance, was formalized in a proof by Seth Gilbert and Nancy Lynch at MIT, building on a conjecture originally proposed by Eric Brewer; their formal proof is the primary academic source. In this context:

  • Consistency means every read receives the most recent write, or an error — no reading stale or conflicting data.
  • Availability means every request receives a non-error response, though not necessarily the most recent write.
  • Partition tolerance means the system continues operating despite network partitions — communication failures between nodes that prevent them from talking to each other.

What the theorem actually proves

The theorem proves that a distributed data system cannot simultaneously guarantee all three properties. IBM’s overview of the CAP theorem summarizes the practical implication clearly: during an actual network partition, a distributed system has to choose between consistency and availability — it cannot provide both at the same time for the affected nodes.

Why partition tolerance isn’t really optional

It might look like a system could just choose consistency and availability, and skip partition tolerance. In practice, this isn’t a real option for any system distributed across multiple nodes or, especially, multiple regions or availability zones: network partitions — however rare — are a real, physically possible event in any distributed system, and a system that isn’t designed to handle one at all will fail in some uncontrolled way when one eventually happens, rather than failing in the deliberate, chosen way CAP describes. This is why CAP is usually discussed as a forced choice between consistency and availability specifically during a partition, not a free three-way choice — partition tolerance isn’t really a design option you decline, it’s a condition every distributed system eventually has to face whether it planned for it or not.

CP versus AP systems, in practice

Databases are often loosely categorized by which side of this trade-off they favor during a partition:

  • CP (consistent, partition-tolerant) systems prioritize consistency during a partition, which means some nodes may become unavailable — refusing requests rather than risking returning stale or conflicting data.
  • AP (available, partition-tolerant) systems prioritize availability during a partition, continuing to serve requests from all reachable nodes, accepting that some responses may reflect slightly stale data until the partition resolves and the system reconciles.

Neither is universally correct — the right choice depends entirely on what a specific application actually needs. A banking ledger generally needs strong consistency, where serving stale balance data is a worse outcome than a temporary error. A social media “like” counter can usually tolerate brief inconsistency in exchange for staying available, since a slightly stale count is a far smaller problem than the feature being unavailable entirely.

How this connects to replication design

This trade-off is exactly what shapes how a database’s replication strategy is designed: how many replicas have to acknowledge a write before it’s considered successful, and what happens when some replicas can’t be reached, are direct expressions of where a given system sits on the consistency-versus-availability spectrum CAP describes.

A common misreading, worth avoiding

CAP is sometimes misapplied as though it forces a permanent, absolute choice at all times, or as though it applies equally to every part of a system uniformly. In practice, many real systems make different consistency-versus-availability trade-offs for different types of data or operations within the same overall architecture — which is a legitimate, deliberate application of the underlying principle to the specific requirements of each piece, not a violation of it.

Key takeaway

The CAP theorem proves that consistency and availability can’t both be fully guaranteed during a network partition — and since partitions are a real possibility any distributed system eventually has to face, that trade-off is a forced design decision, not an optional one. Understanding which side of it a given database prioritizes, and for which specific data, is essential to using it correctly rather than assuming guarantees it was never designed to provide.

This article explains a general distributed systems concept; specific database consistency models vary and should be verified against current vendor documentation. See our disclaimer.