CAP theorem (Brewer’s theorem) says that in a distributed system you can only fully achieve two of three properties at the same time: Consistency , Availability , and Partition tolerance.

Quick Scoop

Think of it as the “Good, Fast, Cheap – pick two” meme, but for distributed databases. When the network misbehaves (which it inevitably does), you must choose what to sacrifice: perfectly up‑to‑date data or always-on responses.

The three letters: C, A, P

  • Consistency (C)
    Every read gets the latest successful write (or an error), no matter which node you hit.

Example: You transfer money between bank accounts; any ATM you use right after must show the updated balance, not an older value.

  • Availability (A)
    Every request receives some non-error response, even if it’s from a node that hasn’t seen the very latest write.

Example: A social feed still loads posts even during a partial outage, but you might see slightly stale likes or comments.

  • Partition tolerance (P)
    The system keeps working even if messages between nodes are lost, delayed, or split into “partitions” because of network issues.

Example: Data centers in different regions temporarily can’t talk to each other, but each region still serves user requests.

In real-world distributed systems, network partitions are considered inevitable , so you must tolerate P and then trade off between C and A during a partition.

What CAP theorem actually claims

In a distributed data store, you cannot provide Consistency, Availability, and Partition tolerance all at once in the presence of a partition.

So during a partition you are forced into one of two behaviors:

  1. CP (Consistency + Partition tolerance)
    • The system chooses to stay consistent even if that means some requests fail or block.
    • During a partition, it may reject or delay requests rather than return stale data.
 * Example: Many traditional relational databases when configured for strict consistency across replicas.
  1. AP (Availability + Partition tolerance)
    • The system chooses to always respond, even if responses are slightly out of date.
    • During a partition, each side keeps serving reads and writes and reconciles later.
 * Example: Many NoSQL systems focusing on high uptime and eventual consistency.

The often-seen “CA / CP / AP” triangle is a simplification: in practice, you only “choose” between C and A when P happens.

Mini example story

Imagine a two-node key–value store holding a variable X.

  1. A network failure splits the two nodes (a partition).
  2. A client writes X = 100 to node A.
  3. Another client reads X from node B (which never received the new value).

Now the system must choose:

  • If node B refuses to answer or errors until it syncs, the system is CP : it keeps consistency but sacrifices availability to some clients.
  • If node B returns its old value (say X = 50), the system is AP : it stays available but loses strict consistency.

That tension is exactly what CAP formalizes.

Why CAP theorem still matters today

  • System design interviews & architecture
    CAP is a staple in backend and microservices discussions, especially for databases in modern cloud-native stacks.

  • Choosing databases
    Many distributed databases lean toward one side:

    • Strong-consistency focused (often CP-style behaviors under partition).
* Highly available, often **eventually consistent** (AP-style).
  • Beyond CAP: newer refinements
    Modern discussions also mention things like PACELC (if Partition, choose A or C; Else, choose Latency or Consistency), which extends CAP to cover “normal” non-partition times too.

Quick TL;DR

  • CAP theorem : In a distributed system, when a network partition happens, you must choose between Consistency and Availability , but you must tolerate Partitions.
  • Most real systems: assume partitions will happen, so they pick CP or AP behavior based on what matters more for their use case—correctness or uptime.

Information gathered from public forums or data available on the internet and portrayed here.