Skip to content
← Back to Notes

The CAP Theorem

1. The Background: The Perfect Database

In a distributed database system, engineers ideally want three guarantees:

  • Consistency (C): Every read receives the most recent write. All nodes have the exact same data at the exact same time.
  • Availability (A): Every request receives a non-error response. The system never goes down.
  • Partition Tolerance (P): The system continues to operate even if the network connecting the database nodes drops or delays messages.

2. The Problem: The Law of Physics

The CAP Theorem states it is physically impossible to guarantee all three simultaneously. Because network failures on the internet are inevitable, Partition Tolerance (P) is mandatory. Therefore, when a network split occurs, you must choose between sacrificing Consistency or sacrificing Availability.

3. The Solutions: CP vs. AP

When the network between databases fails, you must choose an architecture based on your business needs.

Solution A: CP Systems (Consistency + Partition Tolerance)

  • How it works: When a node loses contact with the cluster, it purposefully stops accepting reads and writes to prevent returning stale or conflicting data.
  • The Trade-off: The system throws an error (sacrificing Availability) to guarantee that no user ever reads incorrect data (maintaining Consistency).
  • Use Cases: Banking, financial transactions, inventory control.
  • Databases: MongoDB, Redis, HBase.

Solution B: AP Systems (Availability + Partition Tolerance)

  • How it works: When a node loses contact with the cluster, it stays online and continues to serve user requests using whatever outdated local data it possesses.
  • The Trade-off: Users might read old data or write conflicting data (sacrificing Consistency), but the application never crashes and never throws an error (maintaining Availability).
  • Use Cases: Social media feeds, view counts, shopping carts, recommendation engines.
  • Databases: Apache Cassandra, Amazon DynamoDB, CouchDB.