Scalability
CAP Theorem
In a distributed store, when a network partition occurs you must choose between Consistency (every read sees the latest write) and Availability (every request still gets a response) — you cannot have both during the partition. It frames the core trade-off: CP systems reject requests to stay correct; AP systems answer but may serve stale data.
Purpose
The CAP theorem states that when a network partition splits a distributed store — and partitions are a when, not an if — each side must choose: stay consistent by refusing requests it cannot verify, or stay available by answering with possibly-stale data. You cannot have both during the partition.
When to Use It
It is a lens for choosing and configuring datastores: a bank ledger wants CP behaviour (reject rather than mislead); a social feed wants AP (stale likes beat an error page). Many systems tune per operation — quorum reads where it matters, fast reads where it does not.
Trade-offs
CAP describes only the partition moment; the finer-grained truth (PACELC) adds that else — during normal operation — you still trade latency against consistency. The practical habit it teaches: for every feature, ask what should happen when nodes cannot talk, because something will be sacrificed either way.
Implementation
Pick per data class: strongly consistent stores or quorum settings (e.g. majority reads/writes) for money and inventory; eventually consistent modes for feeds, caches and counters. Design the application to tolerate its choice — retries and errors under CP, reconciliation and idempotency under AP.