api: YAML JSON TOON Database
version: 1.0.0
format: yaml
dataset:
  id: 2740
  slug: cap-theorem
  title: CAP Theorem
  description: "The CAP theorem: a distributed data store can provide only two of three guarantees simultaneously."
  summary: The CAP theorem's three guarantees (consistency, availability and partition tolerance) and what choosing CP or AP implies, extended with the PACELC refinement that describes the latency-versus-consistency trade-off when there is no partition.
  use_when:
    - You are explaining distributed-database trade-offs.
    - You need to check that a CAP claim about a product is stated correctly.
  caveats:
    - CAP applies to behavior during a partition. Saying a database 'is CP' or 'is AP' is a simplification that products often do not fit exactly.
    - Consistency in CAP means linearizability, which is stricter than the 'C' in ACID.
  related:
    - acid-vs-base
    - nosql-databases-overview
    - newsql-distributed-sql
    - database-comparison
  entry_count: 7
  fields:
    - section: data
      field: guarantee
      type: string
      example: Consistency
    - section: data
      field: description
      type: string
      example: Every read receives the most recent write or an…
    - section: data
      field: implication
      type: string
      example: All nodes see the same data at the same time.
    - section: data
      field: tradeoff
      type: string
      example: CP (Consistency + Partition Tolerance)
    - section: data
      field: examples
      type: string
      example: HBase, MongoDB (in strict mode), Bigtable
  category: Database Types
  category_slug: database-types
  tags: database,cap,consistency,availability,partition
  view_count: 52
  created_at: 1793403093
  updated_at: 1793403093
data:
  - guarantee: Consistency
    description: Every read receives the most recent write or an error.
    implication: All nodes see the same data at the same time.
  - guarantee: Availability
    description: Every request receives a response, without guarantee that it contains the most recent write.
    implication: Every node remains operational.
  - guarantee: Partition Tolerance
    description: The system continues to operate despite network partitions.
    implication: Messages between nodes may be lost.
  - tradeoff: CP (Consistency + Partition Tolerance)
    examples: HBase, MongoDB (in strict mode), Bigtable
    description: Sacrifices availability during partitions.
  - tradeoff: AP (Availability + Partition Tolerance)
    examples: Cassandra, DynamoDB, CouchDB
    description: Sacrifices strong consistency during partitions.
  - guarantee: PACELC (extension)
    description: If there is a Partition, choose Availability or Consistency; Else, choose Latency or Consistency.
    implication: Captures that replication costs latency even when the network is healthy.
  - guarantee: CA (single node)
    description: Consistency and availability without partition tolerance, achievable only when there is no network partition to tolerate.
    implication: Describes a single-node or tightly coupled system rather than a distributed one.