CAP Theorem and Read/Write Concerns

What the CAP Theorem Says

When data is stored on several servers (replicas or shards), the network between them can fail. The CAP theorem says that during such a network failure, a distributed database can guarantee only one of these two:

• Consistency (C): every read returns the latest write, or an error.
• Availability (A): every request gets a response, even if the data might be old.

The third letter is Partition tolerance (P): the system keeps working when the network splits servers into groups that can't talk to each other (a network partition). Networks do fail, so P isn't optional. The real choice is C or A when a partition happens.

Think of two bank branches whose phone line goes down. A customer asks branch B for their balance:

• Choose C: "Sorry, we can't confirm your balance right now." Correct, but no answer.
• Choose A: "Your balance is ₹500." An answer, but maybe outdated, if branch A just processed a withdrawal.

1            network partition
2[ Primary ] ──────── ✂ ──────── [ Replica ]
3 latest: wallet = ₹200          still has: wallet = ₹500
4 
5Read arrives at the replica:
6  CP → refuse or wait  → no wrong answer, but an error
7  AP → return ₹500     → always answers, but stale

Not the same C as ACID. ACID consistency means "rules and constraints hold". CAP consistency means "all copies agree on the latest value".

CP vs AP in Our App

Different data in the same app can make different choices:

What About When the Network Is Fine?

CAP only describes failures. Most of the time the network works, and there's still a trade-off: waiting for replicas to confirm makes data safer but slower. This extension is called PACELC: during a Partition choose A or C; Else (normal operation) choose Latency or Consistency.

1Write wallet = ₹200
2  wait for 1 server  → ~2 ms   → fast, a crash may lose it
3  wait for majority  → ~10 ms  → slower, survives a primary crash

That everyday choice is what read and write concerns control.

MongoDB: Write Concern and Read Concern

Write concern answers: "How many servers must confirm a write before it counts as done?"

Read concern answers: "What data am I allowed to see?"

Read preference decides which server to read from: primary (latest) or secondary / secondaryPreferred (spreads load, may be stale).

Tuning these per operation is how you choose consistency or speed for each piece of data:

// wallet: must not be lost or stale
db.wallets.updateOne(
  { userId: 42 },
  { $inc: { balance: -300 } },
  { writeConcern: { w: "majority", j: true } }
);
db.wallets.find({ userId: 42 }).readConcern("majority").readPref("primary");

// menu: fast, slightly stale is fine
db.menuItems.find({ restaurantId: 7 }).readPref("secondaryPreferred");

Interview Angle

Common mistakes:

• Saying "pick any two of C, A, P". You can't give up P in a real network; the choice is C vs A during a partition.
• Confusing CAP consistency with ACID consistency.
• Labelling a whole database "CP" or "AP". Settings like write and read concern change its behaviour per operation.

Summary

1CAP          → during a network partition: Consistency OR Availability
2P            → not optional, networks fail
3CP           → latest data or error → wallets, payments
4AP           → always answers, maybe stale → menus, locations
5PACELC       → no partition: latency vs consistency
6Write concern → w:1 (fast) | w:"majority" (safe) | j:true (journaled)
7Read concern  → local (fast) | majority (no rollback) | linearizable (strongest)
8Read preference → primary (latest) | secondary (spread load, may be stale)

That wraps up scaling. Next, we move into the app side, starting with connection pooling: how Node.js apps share a limited number of database connections.