CAP Theorem (Applies Only to Distributed Database Systems)

Note:

• CAP theorem only and only exists because of distributed database systems
• it will not exist/needed if the database is centralized
• it has nothing to do with monolity/distributed codebase

The CAP theorem describes the trade-offs in how a distributed data store is architected. It applies strictly to databases that span multiple nodes- regardless of how the application tier above it is structured (whether it's a monolith, microservices, or a distributed system of services).

Important

• get basis understanding of distributed database.

The Three Properties

• Consistency: Ensures every read receives the most recent data, or an error.
• Availability: Ensures every read request receives a response, without any guarantee that it is the most recent data.
• Partition Tolerance (specific to network disruption between database nodes): Ensures the system continues to operate even if network communication between nodes is disrupted.

It says that a distributed data store can guarantee at most two of the three properties: consistency, availability, and partition tolerance.

Note

• Partition tolerance is not optional so the choice is between Availability and Consistency

Why Partition Tolerance Is Not Optional

In a distributed system you have multiple database nodes communicating over a network. That network can break - packets drop, links fail, regions isolate. Building for partition tolerance (P) is therefore not optional; you design assuming partitions will happen.

Approaches to implementing Partition Tolerance

Partition tolerance means the cluster keeps making progress (or at least fails in a controlled way) when some nodes cannot talk to others. Common building blocks:

1 Replication

• Keep copies of data on multiple nodes so a subset of the cluster can still serve reads (and sometimes writes) during a split.
• Synchronous vs asynchronous replication changes how “fresh” those copies are when a partition starts.

2 Quorum / majority consensus

• Require a majority (or a configured quorum) of nodes to acknowledge a write or answer a read.
• During a partition, only the side that still holds a quorum can accept writes - the minority side may reject or go read-only. This is how many CP systems stay consistent under split-brain.

3 Consensus protocols (Raft, Paxos, and similar)

• Elect a leader and replicate a log so nodes agree on the order of operations.
• When the network splits, the minority cannot elect or keep a valid leader, so they stop accepting conflicting writes.

4 Conflict detection and resolution (typical of AP designs)

• Allow both sides of a partition to accept writes, then reconcile later with version vectors, last-write-wins, CRDTs, or application-level merge rules.
• Clients stay available; consistency is recovered after the partition heals.

5 Health checks, fencing, and timeouts

• Detect unreachable peers, fence stale leaders, and fail over so a partitioned node cannot keep writing as if it were still authoritative.

6 Topology awareness

• Place replicas across availability zones / regions and define which failure domains you tolerate, so a single network cut does not isolate all copies of critical data.

The Real Trade-off: CP vs AP

Once you assume a network disruption will happen, you must choose:

• Available for all read/write (favor Availability), or
• Wait for connection restoration and prevent partial / conflicting read-write (favor Consistency)

That is the practical CAP choice in distributed databases: CP vs AP (with P already required).

| Choice | Behavior during a partition | Typical fit | | --- | --- | --- | | CP | May refuse or error on some requests until the cluster can agree on the latest state | Money, inventory, bookings | | AP | Keeps responding; data may be stale or diverge until sync | Feeds, likes, soft state |

Important Note: CAP Is About the Database Layer

If something goes wrong with data at the server / application service layer - for example a distributed services network issue between microservices - that is not covered by CAP.

CAP only applies to the database (distributed data store) layer. Application-level failures, service mesh outages, and API gateway problems are separate concerns.

Examples

Banking application → Consistency over Availability

Prefer CP: better to return an error or delay a transfer than to allow partial or false balances when nodes cannot agree. Preventing incorrect debit/credit during a partition matters more than answering every request immediately.

Social media feed → Availability over Consistency

Prefer AP: an outdated like count or a comment that appears a few seconds late after sync is usually acceptable. Keeping the feed readable and writable during a partition is more important than perfect real-time consistency.

Takeaways

1. CAP is a distributed database theorem - not a general microservices theorem.
2. In real distributed stores, partition tolerance is assumed; the design choice is mainly C vs A when the network splits.
3. Pick CP when wrong data is worse than downtime; pick AP when stale or eventually consistent data is acceptable.