Engineering Fluency OS

Why This Matters

When you build a system that runs across multiple servers, you face an impossible choice. The CAP theorem proves you cannot have all three of consistency, availability, and partition tolerance at the same time. Every distributed database, every replicated cache, every multi-region service must pick a side. Understanding CAP is the first step toward making informed architecture decisions instead of hoping your system "just works."

If you have ever wondered why some databases seem to return stale data, or why others become unavailable during network issues, CAP is the answer.

Define Terms

Visual Model

ConsistencyAll nodes see same data

AvailabilityEvery request gets a response

Partition ToleranceSystem works despite network splits

CP SystemsZooKeeper, etcd, HBase

AP SystemsCassandra, DynamoDB, CouchDB

CA SystemsSingle-node RDBMS (no partition)

The full process at a glance. Click Start tour to walk through each step.

During a network partition, a distributed system must choose between consistency (CP) and availability (AP).

Code Example

Code

// Simulating CAP theorem tradeoffs

// CP System: Rejects requests during partition
class CPDatabase {
  constructor() {
    this.data = new Map();
    this.isPartitioned = false;
  }

  write(key, value) {
    if (this.isPartitioned) {
      throw new Error("Service unavailable: cannot confirm consistency");
    }
    this.data.set(key, value);
    return { status: "ok", consistent: true };
  }

  read(key) {
    if (this.isPartitioned) {
      throw new Error("Service unavailable: cannot confirm consistency");
    }
    return this.data.get(key);
  }
}

// AP System: Always responds, may be stale
class APDatabase {
  constructor() {
    this.localData = new Map();
    this.isPartitioned = false;
  }

  write(key, value) {
    this.localData.set(key, { value, timestamp: Date.now() });
    // Best-effort replication (may fail during partition)
    return { status: "ok", consistent: !this.isPartitioned };
  }

  read(key) {
    const record = this.localData.get(key);
    return record ? record.value : undefined;
    // Always responds, even if stale
  }
}

const cp = new CPDatabase();
cp.write("user:1", "Alice");
cp.isPartitioned = true;
try {
  cp.read("user:1");
} catch (e) {
  console.log("CP error:", e.message);
}

const ap = new APDatabase();
ap.write("user:1", "Alice");
ap.isPartitioned = true;
console.log("AP result:", ap.read("user:1"));

Interactive Experiment

Try these exercises to solidify your understanding:

Modify the CP system to add a timeout — if the partition heals within 3 seconds, return the data; otherwise error.
Add a lastSyncTime field to the AP system that tracks when data was last confirmed consistent.
Think about your favorite web app. Is it CP or AP? What happens when your internet is flaky?
Consider a banking app vs. a social media feed. Which should be CP? Which can be AP?

Quick Quiz

Coding Challenge

Quorum Checker

Write a function called `canAchieveQuorum` that takes the total number of nodes and the number of reachable nodes, and returns true if a majority quorum is possible (more than half the nodes are reachable). A quorum lets a CP system confirm consistency.

Loading editor...

Real-World Usage

The CAP theorem shapes how major systems are built:

Banking systems (CP): Your bank balance must be consistent. If the system is unsure, it rejects the transaction rather than showing wrong numbers.
DNS (AP): The Domain Name System is eventually consistent. A DNS update may take hours to propagate, but DNS always responds.
Cassandra (AP): Social media feeds, IoT sensor data, and logging systems that prefer availability over perfect consistency.
etcd/ZooKeeper (CP): Configuration management and leader election where correctness is more important than uptime.

CAP Theorem