Consistency & CoordinationChapter 13 · Agree to disagree
Consistency models: strong to eventual
Consistency models: strong to eventual
A consistency model is the promise a replicated store makes about what a read can return. At the top, linearizable (strong) — it behaves like one copy, so a read never misses a write that finished before it began. Below it come sequential, causal and finally eventual, which only promises the copies agree once writes stop. Session guarantees such as read-your-writes are smaller promises to one client. Every step up removes surprises but makes reads or writes wait longer and fail more often when machines can't reach each other.
- Use when
- Deciding which screens may show slightly old data and which must not — a running balance vs a like count · Reading a database's consistency setting before trusting a read after a write · Explaining a bug report where two users, or two devices, disagree about the same data
- Avoid when
- Choosing strong consistency for everything by default — it pays in latency and availability for reads that didn't need it · Treating isolation levels as the same thing — those are about concurrent transactions (Consistency leg 2)
- Trade-offs
- Stronger models need more replicas to agree before answering, so reads and writes wait longer · Stronger models stop answering sooner when replicas can't reach each other (core/cap-pacelc) · Weaker models are fast and always answer, but the app must cope with old or out-of-order data
- Requires
- Replication lag & read-your-writes
3 objectives · 5 misconceptions
- explain Explain linearizable, sequential, causal and eventual consistency by what each one forbids a read to return, and place the session guarantees — read-your-writes, monotonic reads, monotonic writes, writes-follow-reads — below causal.
- diagnose Diagnose which guarantee a reported anomaly breaks — a member's own expense missing, a balance going back in time, a reply showing before the message it answers, two members seeing different totals.
- choose Choose a model for each Ledger screen from what it can't tolerate and what each rung costs, and read a managed store's offer — Cosmos DB's five levels, DynamoDB's read flag, Spanner, S3 — for the rung it gives.
- Not true: Strong consistency just means the replicas copy data quickly.
- Not true: Eventual consistency promises the copies agree within a second or so.
- Not true: There are only two choices — strong or eventual.
- Not true: If every user always sees their own changes, the system is strongly consistent.
- Not true: The safe design is to make every read strongly consistent.