CAP Theorem

It's 3am. A construction crew accidentally cuts a fibre cable between two AWS data centres. Suddenly, your London servers can't talk to your Dublin servers. Your database is split in two — and it has to make an instant decision: do I keep accepting writes and risk the two halves getting out of sync? Or do I refuse all writes until the connection is restored? That decision — made in milliseconds, automatically — is what CAP Theorem is about. And every distributed database you'll ever use has already made it.

Why This Only Matters When You Have Multiple Servers

On a single server, none of this matters. You write data, it's saved, anyone who reads gets the latest version. Simple. But the moment you add a second server — for redundancy, for performance, for scale — you've entered distributed systems territory, and a hard mathematical reality kicks in.

The Three Letters — One Analogy Each

CAP stands for Consistency, Availability, and Partition Tolerance. Every database textbook makes these sound complicated. They aren't. Here's each one in plain English:

The Brutal Truth — Why You Can Only Pick Two

In 2000, computer scientist Eric Brewer proved that no distributed system can guarantee all three properties simultaneously. This became CAP Theorem. Let's prove it with a concrete scenario so it clicks permanently.

The CAP Triangle

Every database sits on one edge of this triangle — getting the two properties at that edge, and giving up the one at the opposite corner:

CP in Action — MongoDB Under a Partition

MongoDB is a CP database. When a partition happens, it chooses to protect data consistency — even if that means refusing writes temporarily. Here's exactly what that looks like in code:

The scenario: You're a backend engineer. Your MongoDB replica set has 3 nodes. One node goes down — maybe a network split, maybe a server crash. You try to write a payment record. Here's what MongoDB does:

// Connect to MongoDB replica set
const client = new MongoClient(
  "mongodb://node1,node2,node3/payments_db?replicaSet=rs0"
)

// Write with "majority" concern
// This means: confirm that MOST nodes received this write
const result = await db.collection("payments").insertOne(
  { user_id: "u_441", amount: 250, status: "confirmed" },
  { writeConcern: { w: "majority" } }
)

// What happens when node2 and node3 are unreachable
// MongoDB cannot reach "majority" — so it REFUSES the write
// This is CP behaviour: protect consistency over availability

MongoServerError: Write concern error
{
  code: 91,
  codeName: "ShutdownInProgress",
  errmsg: "Not enough data-bearing nodes are available to satisfy the write concern",
  writeConcernError: {
    code: 100,
    writeConcernError: "waiting for replication timed out"
  }
}

AP in Action — Cassandra Under a Partition

Cassandra is an AP database. When a partition happens, it keeps accepting writes and reads — even from nodes that might be behind. It chooses to stay available, accepting that some reads might be slightly stale.

The scenario: Same situation — network split, one node unreachable. You write a user activity event. Watch what Cassandra does differently:

from cassandra.cluster import Cluster
from cassandra import ConsistencyLevel
from cassandra.query import SimpleStatement

cluster = Cluster(['node1', 'node2', 'node3'])
session = cluster.connect('analytics')

# Write with consistency level ONE
# ONE means: just one node needs to confirm — then we're done
query = SimpleStatement(
  "INSERT INTO page_views (user_id, page, ts) VALUES (%s, %s, %s)",
  consistency_level=ConsistencyLevel.ONE
)

session.execute(query, ('u_441', '/checkout', datetime.now()))

-- Even with node3 unreachable, Cassandra responds:

Write acknowledged by node1
Status: SUCCESS

-- node3 will sync when it comes back online
-- via Cassandra's "hinted handoff" mechanism

What Actually Happens During a Network Partition

Here's the same event — a network split between two data centres — shown through the eyes of three different database types:

Which Type Should You Choose?

Practice Questions — You're the Engineer

Quiz — Network Just Split. What Does Your Database Do?