Manu's Vault

CAP Theorem

5 min readStatus:Seedling

Core Idea

The CAP theorem states that a distributed data system cannot simultaneously guarantee Consistency, Availability, and Partition-Tolerance—in practice, one must choose between consistency and availability when partitions occur.

Definition

The CAP Theorem, formulated by Eric Brewer in 2000 and formally proven by Seth Gilbert and Nancy Lynch in 2002, states that a distributed data system cannot simultaneously guarantee all three of the following properties: Consistency (all nodes see the same data at the same time), Availability (every request receives a response), and Partition-Tolerance (the system continues to operate despite network failures). In practice, since network partitions are inevitable in distributed systems, the theorem reduces to a choice between consistency and availability when partitions occur.

Key Characteristics

  • Consistency (C): Any read operation that begins after a write operation completes must return that value or a more recent write. Also known as linearizability—a very specific and strong notion of consistency where the system behaves as if there is only a single copy of the data.

  • Availability (A): Every request received by a non-failing node in the system must result in a response, without guarantee that it contains the most recent write. The system remains responsive even during network disruptions.

  • Partition-Tolerance (P): The system continues to operate despite arbitrary message loss or failure of part of the system. The network is allowed to lose messages sent from one node to another, yet the system still functions.

  • The Trade-off: During a network partition, a system must choose between rejecting requests (sacrificing availability) to maintain consistency, or accepting requests on isolated nodes (sacrificing consistency) to maintain availability.

  • CP Systems: Prioritize Consistency and Partition-Tolerance. They reject or delay requests during partitions to prevent conflicting data. Examples: MongoDB, HBase, Redis, and systems requiring strong ACID transactional guarantees (e.g., banking applications, ticket booking systems).

  • AP Systems: Prioritize availability and Partition-Tolerance. They accept writes on isolated nodes and reconcile differences once connectivity returns, using Eventual-Consistency. Examples: Cassandra, CouchDB, DynamoDB, and systems where continuous operation is critical (e.g., shopping carts, social media feeds).

  • Modern Nuance: Eric Brewer later clarified (2012) that the “two out of three” framing is misleading because designers only sacrifice C or A during partitions. Outside partitions, there is flexibility in balancing consistency and performance. Most modern distributed databases offer tunable consistency levels.

Examples

  • Financial Systems: A banking application prioritizes consistency (CP) to prevent showing incorrect account balances or allowing overdrafts. During network partitions, it may reject transactions rather than risk data inconsistencies.

  • E-commerce Inventory: An online store might choose availability (AP) for shopping cart operations while using consistency (CP) for final checkout to prevent overselling. The cart can tolerate temporary inconsistencies, but payment processing cannot.

  • Social Media Feeds: Platforms like Twitter prioritize availability (AP), allowing users to post and read even during network issues. Temporary inconsistencies (e.g., follower counts, like counts) are acceptable and eventually reconcile.

  • DNS Systems: The Domain Name System is AP by design—it remains available even when authoritative servers are unreachable, serving cached (potentially stale) data rather than failing to respond.

  • Apache Cassandra Configuration: Demonstrates tunability—write/read operations can be configured with different consistency levels (ONE, QUORUM, ALL), allowing applications to trade consistency for availability based on specific use case requirements.

Why It Matters

The CAP Theorem fundamentally shaped how architects reason about distributed systems trade-offs, forcing explicit consideration of failure scenarios rather than assuming perfect network reliability. However, its limitations have become increasingly recognized: the theorem only considers network partitions (not node crashes or other failures), models a single read-write register (not multi-object Distributed-Transactions), and reduces complex consistency models to a binary choice. Martin Kleppmann’s critique (2015) argues that CP/AP labels oversimplify real systems and proposes alternative frameworks like “delay-sensitivity” analysis. The PACELC theorem extends CAP by recognizing that even without partitions, systems must trade latency for consistency. Understanding CAP’s historical influence and modern limitations helps architects make informed decisions about consistency guarantees, Fault-Tolerance, and user experience in distributed architectures.

Sources

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.

Graph View

Backlinks