When a database is spread across multiple machines, three properties become impossible to guarantee simultaneously: consistency, availability, and partition tolerance. Eric Brewer's CAP theorem, formalised in 2002, states that any distributed data store can satisfy at most two of the three. Every architect of a big data system must understand which two their chosen database prioritises and what the trade-off costs in real failure scenarios, because the answer determines whether the system is safe to use for critical data or must be supplemented with compensating logic.
Partition tolerance — the ability to continue operating when network messages between nodes are lost — is not optional in any distributed system deployed across data centres. The only question is whether the system continues serving requests during a partition (choosing availability) or refuses requests until the partition heals (choosing consistency). This is why practitioners say the real CAP choice is between CP and AP, not whether to include partition tolerance at all.
Real distributed systems do not occupy a fixed position in the CAP triangle — they offer tunable consistency levels that let applications choose per-operation. Apache Cassandra is labelled AP but offers `QUORUM` reads that approach consistency. HBase is labelled CP but can be configured for eventual consistency reads. Understanding that CAP describes worst-case behaviour under partition — not steady-state behaviour — prevents the mistake of treating a database's CAP label as its only relevant property.