ทฤษฎีบท CAP แบบเข้าใจง่าย

Spreading data across many servers buys scale but brings distributed systems headaches: nodes must agree even when the network hiccups. Enter the CAP theorem.

The CAP theorem says a distributed store can guarantee only two of three: Consistency, Availability, and Partition tolerance. The catch: partitions always happen.

Consistency means every read sees the latest write, from any node. Deposit money and check any ATM — you'd see the new balance. Reliable, but it costs speed.

Availability means every request gets a response — never an error, even if the answer is slightly stale. A cart that always lets you add items chose this.

A partition is when nodes can't talk to each other — and in real networks, it will happen. So the real choice is always Consistency vs Availability during one.

CP systems pick consistency: during a partition they'd rather return an error than stale data. Right for ledgers and inventory, where wrong answers are costly.

AP systems pick availability: they always answer, even with slightly old data, then sync up later. Perfect for social feeds, reviews, and shopping carts.

MongoDB is CP by default. Only the primary node takes writes, so during a partition it briefly pauses writes rather than risk conflicts. The code shows read options.

Eventual consistency means nodes may briefly disagree, but given a moment, all reads catch up to the latest value. Nothing is lost — it just takes a beat.

CAP only covers partitions, which are rare. PACELC adds the everyday trade-off: even with no partition, you choose between low latency and strong consistency.

CAP helps you design wisely: expect slightly stale data, handle retries gracefully, and pick majority write concern for critical operations. The code shows how.

You learned the CAP theorem, why partition tolerance is non-negotiable, and that MongoDB is CP by default. Next: exactly where MongoDB fits best.