đź‘‹ alhassanaraouf

  • Notes

    where I share what I've learned

  • Life

    where I write about my adventures

  • Posts

    my longer form thoughts

  • Projects

    cool things I've made

Recent Notes

CAP Theorem

3 min read

CAP Theorem

Overview

The CAP Theorem, proposed by Eric Brewer, states that a distributed system cannot simultaneously guarantee all three of the following properties:

  • Consistency (C): Every read receives the most recent write or an error.
  • Availability (A): Every request receives a non-error response, without the guarantee that it contains the most recent write.
  • Partition Tolerance (P): The system continues to operate despite arbitrary message loss or failure of part of the system (network partition).
TermFormal MeaningEveryday Analogy
Consistency (C)Every read that begins after a successful write must return that write (linearizability).“Everyone sees the same latest tweet immediately.”
Availability (A)Every non‑failing node must respond to every request in finite time (no errors, no timeouts).“No branch ever closes its doors.”
Partition Tolerance (P)The system continues to operate despite dropped/delayed messages between nodes.“Two offices can’t phone each other, but must still do business.”

In the presence of a network partition, a distributed system must choose between Consistency and Availability.

Because the internet is not perfect, P is non‑negotiable—you have to assume it might happen. So day‑to‑day design is really a C vs A trade‑off during a partition window.

Visual Representation

image-4.png

Trade-Offs

Depending on the system design and its use case, only two out of the three CAP properties can be fully achieved at any time.

1. CP – Consistency + Partition Tolerance

  • Guarantees data consistency even when partitions occur.
  • May sacrifice availability (some operations are blocked until the partition resolves).
  • Examples: HBase, MongoDB, Redis (in strict mode)
  • Use Cases: Financial systems, account balances, order processing.

2. AP – Availability + Partition Tolerance

  • The system remains operational during partitions.
  • Data may be stale (eventual consistency).
  • Examples: Cassandra, CouchDB, DynamoDB
  • Use Cases: Social media feeds, product recommendations, shopping carts.

3. CA – Consistency + Availability

  • Assumes no network partitions (ideal conditions).
  • Cannot maintain operation during a partition.
  • Examples: Traditional RDBMS (e.g., MySQL, PostgreSQL) in a single-node setup.
  • Use Cases: Enterprise systems with reliable infrastructure, local apps.

Practical Implications

In real-world systems where partitions are inevitable, developers and architects must decide:

  • If Consistency is more important than Availability → choose CP.
  • If Availability is more important than Consistency → choose AP.

For example:

  • Banking applications favor CP to avoid inconsistent balances.
  • E-commerce websites may favor AP to ensure users can browse and add items to cart even during network issues.

 Design Checklist for Your Own System

QuestionWhy It Matters
What is my tolerable stale window? (seconds, minutes, never)Dictates if eventual or quorum reads are acceptable.
How costly is downtime vs double‑spend?Drives CP vs AP tilt.
Can I isolate strongly‑consistent core data from looser peripheral data?Hybrid architectures (e.g., orders in CP store, activity feed in AP store).
What is my network topology & round-trip time (RTT)?Determines how painful synchronous cross‑region commits are.
Do I have a clear conflict resolution strategy?Needed if you ever accept concurrent divergent writes.

Conclusion

The CAP Theorem is a foundational concept in distributed system design. It guides architects in making trade-offs that best suit their application’s needs, based on the tolerance for latency, availability, and data correctness.

Graph View

Backlinks