Why Banks Let You Wait but Never Miscalculate: A 5‑Minute Guide to the CAP Theorem

CAP theorem basics

Consistency (C) requires that all nodes see exactly the same data at the same moment. The article illustrates this with an online document where every collaborator must see the same title after a change.

Availability (A) means every request receives a non‑error response within a bounded time. The analogy used is a 24 × 7 convenience store that never closes its doors.

Partition tolerance (P) requires the system to continue operating when network links between nodes break. Network partitions are inevitable because cables can be cut, routers can overheat, or traffic spikes can cause congestion.

Core conclusion of CAP

When a partition occurs, at most two of the three properties can be satisfied. The article demonstrates this with a write that succeeds on node A while a read reaches isolated node B. The system must either return stale data (preserving availability, breaking consistency) or refuse to respond (preserving consistency, breaking availability). Therefore, during a partition, C and A are mutually exclusive, and P is compulsory, leaving only CP or AP designs.

Choosing between CP and AP

CP architecture prioritises consistency and partition tolerance, sacrificing availability. In a network partition the system may pause service rather than return incorrect data. Typical CP scenarios include bank transfers, payment services, and distributed locks. Widely used CP coordination services are ZooKeeper and etcd, which prefer to time out instead of returning inconsistent results.

AP architecture prioritises availability and partition tolerance, sacrificing strong consistency. The system continues to serve requests during a partition, but the data returned may be slightly stale. Typical AP scenarios are social‑media likes, short‑video follower counts, and collection numbers, where a delayed count is acceptable. Representative AP systems are Cassandra (default AP with tunable consistency) and CouchDB.

Common misconceptions

CAP can satisfy all three properties. Gilbert and Lynch proved mathematically in 2002 that C, A, and P cannot be simultaneously achieved in a distributed system.

Partition tolerance can be dropped. Partition tolerance is unavoidable in any multi‑node system; abandoning it reduces the system to a single‑node setup, which defeats the purpose of distribution.

Consistency only means strong consistency. Consistency also includes eventual consistency, which leads to the BASE model.

BASE model

In 2008 Dan Pritchett introduced BASE (Basically Available, Soft state, Eventually consistent) as a pragmatic compromise for AP systems.

Basically Available : the system may respond slower or with degraded functionality during failures but never becomes completely unavailable.

Soft state : intermediate data states are allowed; the system does not require every node to be perfectly up‑to‑date at all times.

Eventually consistent : data will converge to a consistent state after some time.

Examples given are an e‑commerce product inventory that may show a slightly stale count but corrects after a few seconds, and a food‑delivery order status that lags briefly before becoming accurate.

Practical selection rule

Money‑related services (e.g., banking, payments) should choose CP – “better to wait than to be wrong.” Social‑content services (e.g., likes, follower counts) should choose AP – “better to be slightly behind than to disappear.” Accepting the inherent imperfection of distributed systems and applying the BASE model enables reliable, responsive applications despite the CAP limitation.