Consistency Models and the CAP Trade-off
Replica consistency describes what clients may observe. When network partitions can persist, a store cannot guarantee both linearizable operations and successful responses to every request at a non-failing node. Application requirements guide which guarantees its design must support.
What a learner can do afterwards
- Say what a client can observe under strong consistency and under eventual consistency
- Work out what each side of a partitioned system may do under each choice
- Choose a consistency model for a stated application and defend the choice
1 · Read
Replicas hold copies of data. Here, strong consistency means linearizability: operations behave like one ordered copy, respecting real-time order. A read begun after a write completes must reflect that write or a later one. Overlapping operations may be ordered either way. This differs from transaction isolation, which governs how transactions interact.
A partition prevents communication between replicas and may last indefinitely. CAP availability requires every request received by a non-failing node eventually to get a successful response. A timeout or refusal is not that guarantee. A store cannot guarantee both this availability and linearizability despite partitions. Preserving consistency may require delaying or refusing operations.
Replicas R and S start at 4. A partition separates them. R completes a write of 9, then S receives a read. With no later write, returning 4 violates linearizability. S cannot learn 9 across the broken link, so guaranteeing consistency may require waiting or refusing the read. Depending on the protocol, one side or both may pause.
Eventual consistency permits disagreement. If updates stop and communication and reconciliation succeed, replicas eventually converge. It gives no fixed deadline and does not itself guarantee CAP availability. A basket may accept additions on both sides and merge by set union, which retains every distinct item from either side. Adding oats and milk separately then retains both. Removals need a defined conflict policy too.
Choose guarantees from each feature's rules. A debit that must not overdraw needs coordinated checks or another overspending-prevention design. A basket may tolerate stale views and a merge policy. Strong reads and writes do not make a read-check-write sequence atomic: two buyers can each read 3 seats and write 1 after reserving 2, making 4 reservations. Use an atomic check-and-update or another safe allocation rule.
CAP concerns linearizability and availability during partitions. Eventual convergence has conditions. Application rules also need suitable atomic operations and conflict policies.
Lesson, questions and flashcards on replica consistency written for this dataset.
2 · Watch
Take it off screen
Where it sits
Learn first
Optional connections
This opens up
8 questions wait behind this lesson, each with its answer explained. Every answer feeds the sky: stars light as they are learned, and dim when it is time to come back.