CAP Theorem & Consistency Models
Why a distributed system can't have perfect consistency, availability, and partition tolerance all at once — and what real systems trade off.
Try answering in your head first, then click a question to check the model answer.
Q1.Explain why CAP theorem's trade-off really only bites during a network partition, not during normal operation.(show answer)
When there's no partition, a well-designed system can provide both strong consistency and availability simultaneously — nodes can communicate freely to agree on data. CAP theorem's forced trade-off only kicks in during a partition: a node cut off from the others must choose between responding anyway (possibly with stale/inconsistent data — favoring Availability) or refusing to respond until it can confirm consistency with the rest of the cluster (favoring Consistency).
Q2.Give a real-world scenario where an AP (available, eventually consistent) system is an acceptable, even good, design choice.(show answer)
A social media "like" counter or a shopping cart — briefly showing a slightly stale like count, or momentarily inconsistent cart state across devices, is a minor, self-correcting UX issue. The system staying available and responsive (rather than rejecting requests during a partition to guarantee perfect consistency) matters far more to the user experience than perfect real-time accuracy in these cases.
Q3.Give a scenario where a CP (consistent, less available) system is the right trade-off instead.(show answer)
A banking system processing an account balance transfer — serving a stale or incorrect balance (or allowing a double-spend during a partition) could cause real financial harm. Here it's better for the system to refuse the operation (unavailable) during a partition than to risk an inconsistent result, since correctness matters more than uptime for this specific operation.
Q4.How does eventual consistency differ from strong consistency in what guarantees an application can rely on?(show answer)
Strong consistency guarantees that once a write completes, any subsequent read (from any node) sees that write immediately — reasoning about the system is simple, but it requires coordination that can hurt availability/latency, especially across geographically distributed nodes. Eventual consistency only guarantees convergence eventually if writes stop — reads can return stale data for some period after a write, which is faster and more available, but the application must be designed to tolerate temporarily seeing outdated data.