The CAP Theorem

Overview

CAP describes consistency (every read sees the latest write, everywhere), availability (the system keeps responding to requests), and partition tolerance (the system keeps operating even when nodes can't communicate). The common "choose two of three" framing is slightly misleading: partition tolerance isn't a real, standing choice, network partitions happen regardless of what a system "picks," so the actual decision CAP describes only activates during a real partition, and it's a choice between consistency and availability specifically in that moment, not a constant, permanent trade-off a system lives with at all times. A CP system pauses or rejects requests during a partition to guarantee correctness (a bank refusing a transfer rather than risking a duplicate); an AP system keeps responding and reconciles afterward (a chat app that stays usable through a network split). Systems like MongoDB make this a concrete, tunable choice via write concern and read preference, not an abstract, fixed architectural decision.

Quick Reference

Syntax

// MongoDB - w: 'majority' waits for the write to be acknowledged
// (and durable) on a majority of replicas before returning.
db.collection.insertOne(doc, { writeConcern: { w: 'majority' } });

// w: 1 only waits for acknowledgment from the primary, a weaker
// durability guarantee in exchange for a faster write.
db.collection.insertOne(doc, { writeConcern: { w: 1 } });

Examples

// Reading from a secondary favors availability over strict
// consistency; the data returned might lag the primary. Whether a
// read reliably sees a prior write depends on readConcern, session
// (causal consistency), and readPref together, not readPref alone.
db.collection.find().readPref('secondary');

Visual Diagram

Common Mistakes

• Treating "choose two of three" as a constant, standing architectural decision, rather than a choice that only actually activates during a real network partition.
• Assuming partition tolerance is optional for a distributed system, when network partitions are a fact of distributed operation, not an avoidable scenario.
• Picking CP or AP for an entire system uniformly, when different operations within the same system (a payment versus a "last seen" timestamp) often warrant different choices.
• Confusing CAP's consistency (every read sees the latest write) with ACID's consistency (a transaction moves the database from one valid state to another), they are different, related-sounding concepts.

Performance

• CP behavior during a partition trades availability (rejected/paused requests) for correctness; the "cost" is measured in failed or delayed requests during the partition window, not steady-state latency.
• AP behavior keeps latency and availability high during a partition at the cost of temporary inconsistency that has to be reconciled afterward, real reconciliation work, not a free lunch.

Best Practices

• Decide CP versus AP per operation based on what a wrong answer actually costs, financial correctness usually demands CP, a social feed usually tolerates AP.
• Use tunable consistency settings (write concern, read preference, quorum size) where the database supports them, rather than treating CP/AP as a fixed, whole-system choice.
• Design explicitly for the reconciliation step an AP choice implies, conflicting writes made during a partition don't resolve themselves.
• Don't conflate CAP's "consistency" with ACID's; know which one a given conversation or requirement is actually about.