Consistency Models
Strong, eventual, causal — 'consistent' means very different things, each with a price.
By the end of this lesson, distinguish consistency models and apply CAP/PACELC to pick one deliberately.
When data is replicated across nodes, 'consistency' asks: after a write, what are readers guaranteed to see? The answers form a spectrum. Strong/linearizable: every read sees the latest write, as if there were one copy. Eventual: replicas converge if writes stop, but a read may be stale. Causal: operations that are causally related are seen in order, but unrelated ones may differ.
First, see the whole system. Then we’ll open it up.
CAP under a partition
- During a network partition you must choose: CP (stay consistent by refusing some requests) or AP (stay available by accepting possibly-divergent writes). With no partition you can have both.
flowchart TB
p{Network partition?} -->|yes| choose{Choose}
choose --> CP[CP: refuse writes, stay consistent]
choose --> AP[AP: accept writes, risk divergence]
p -->|no| both[Serve fast and consistent]CAP says that under a network partition you must trade consistency (C) against availability (A). PACELC completes it: even when there's no partition (E, else), you trade latency (L) against consistency (C). Strong consistency requires coordination, and coordination costs latency — always. There is no free strong consistency.
Strong consistency gives simple, correct reads but costs latency and availability (coordination on every operation, refusal under partition). Eventual consistency gives speed and availability but pushes conflict handling and 'read-your-writes' concerns onto the application.
What does PACELC add to CAP?
That even without a partition (Else), you still trade Latency against Consistency — coordination for strong consistency always costs latency.