🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

📏 धडा 07 — Consistency models: प्रत्येक जण वाचणाऱ्याला काय वचन देतो

📍 तुम्ही इथे आहात: 12 पैकी धडा 07 · मागे: lesson-06-quorums · पुढे: lesson-08-cap-pacelc

📦 या ब्रँचमध्ये काय आहे

धडे 01–06, अधिक data च्या प्रती असताना वाचणाऱ्याला काय वचन मिळते त्याची नावे: linearizable, sequential, causal, read-your-writes, monotonic reads आणि eventual consistency — सर्वात मजबूत पासून सर्वात कमकुवत पर्यंत — आणि प्रत्येकाची किंमत काय. dist/demo.py मधले models() त्यांची यादी देते; खालचा snippet धडा 06 मधले QuorumStore वापरून त्यापैकी दोन जाणूनबुजून मोडतो.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

सगळे एकच प्रश्न विचारतात: "Exam कोणत्या दिवशी आहे?" शाखा उत्तराबद्दल वेगवेगळी वचने देऊ शकतात.

🥇 "जणू एकच नोंदवही आहे." एकदा कोणीही "Tuesday" पाहिले की, कुठेही कोणालाच पुन्हा कधीच "Monday" दिसणार नाही. (linearizable)
🥈 "सगळ्यांना बदल एकाच क्रमाने दिसतात." कदाचित थोडे उशिरा, पण कधीच वेगळ्या क्रमाने नाही. (sequential)
🥉 "कारण आधी, परिणाम नंतर." तुम्ही "exam पुढे ढकलली" ही notice पाहिली असेल, तर ती ज्या नव्या timetable बद्दल बोलते तोही तुम्हाला दिसेल. (causal)
🙋 "तुम्हाला तुमचा स्वतःचा बदल दिसतो." दीपिकाने notice बदलली, म्हणून दीपिकाला तिचा बदल नेहमी दिसतो. इतरांना अजून जुनी दिसू शकते. (read-your-writes)
⏩ "कधीच मागच्या वेळेत नाही." कतरिनाने एकदा Tuesday पाहिले की, तिला नंतर Monday दिसणार नाही. (monotonic reads)
🌫️ "शेवटी सगळे सहमत होतात." लोकांनी बदल करणे थांबवले तर सगळ्या प्रती जुळतील — कधीतरी. तोपर्यंत काहीही दिसू शकते. (eventual)

मजबूत वचने छान असतात. त्यांना जास्त थांबावे लागते आणि जास्त निरोपे लागतात.

🗺️ आकृती

flowchart TB
    lin["🥇 linearizable<br/>one copy, real-time order"] --> seq["🥈 sequential<br/>one order for all, maybe late"]
    seq --> cau["🥉 causal<br/>cause before effect"]
    cau --> ryw["🙋 read-your-writes<br/>you see your own change"]
    cau --> mr["⏩ monotonic reads<br/>never back in time"]
    ryw --> ev["🌫️ eventual<br/>copies agree when writes stop"]
    mr --> ev
    cost["⬆️ stronger = more coordination<br/>more latency, less availability"]

🗺️ काढलेली आवृत्ती + एक lab: https://school-edh.pages.dev/distributed-systems/lesson-diagrams.html#l07

❓ काय

Consistency model — data store आणि त्याचे वाचणारे यांच्यातला करार: जे writes झाले ते पाहता, read कोणत्या values परत देऊ शकतो.
Linearizable (strong consistency, "atomic") — प्रत्येक operation त्याच्या सुरुवात आणि शेवट यांच्यामधल्या एका क्षणी घडल्यासारखे दिसते, खऱ्या वेळेशी जुळणाऱ्या क्रमाने. एकदा write पूर्ण झाला की, नंतरचा प्रत्येक read (कोणाचाही) तो किंवा त्याहून नवे काहीतरी पाहतो. ते जणू एकच प्रत असल्यासारखे वागते. CAP मधले "C" हेच (धडा 08).
Sequential — सगळे nodes सगळे operations एकाच क्रमाने पाहतात, आणि प्रत्येक client चे स्वतःचे operations त्या client ने ते ज्या क्रमाने केले त्याच क्रमाने दिसतात. Linearizable च्या उलट, तो क्रम खऱ्या वेळेशी जुळायलाच हवा असे नाही: read थोडा मागे असू शकतो.
Causal — causally related (धडा 03) operations सगळ्यांना त्याच क्रमाने दिसतात. Concurrent operations वेगवेगळ्या nodes ना वेगवेगळ्या क्रमाने दिसू शकतात. Network partition दरम्यान available राहू शकणारा हा सर्वात मजबूत model आहे.
Read-your-writes (read-your-own-writes) — client ला नेहमी त्याचे स्वतःचे आधीचे writes दिसतात. इतर clients ना कदाचित अजून नाही.
Monotonic reads — client ला नवी value पाहिल्यानंतर कधीच जुनी value दिसत नाही. एकाच user चे reads वेगवेगळा lag असलेल्या वेगवेगळ्या replicas कडे गेले की हे सहसा मोडते.
Eventual — writes थांबले तर सगळ्या प्रती कधीतरी एकाच value वर येतात. केव्हा याचे वचन नाही, आणि मधल्या काळात read काय परत देईल याचेही वचन नाही.
Session guarantees — read-your-writes, monotonic reads (आणि आणखी दोन: monotonic writes, writes-follow-reads) ही प्रत्येक client session साठीची वचने आहेत; eventual consistency वर ती जोडणे स्वस्त आहे, उदाहरणार्थ एका user चे reads एकाच replica कडे पाठवून.

🤔 का

कारण "consistent" चा अर्थ वेगवेगळ्या लोकांसाठी वेगवेगळा असतो, आणि bugs त्या फरकात राहतात. एखादी item दाखवणारा, मग लपवणारा, मग पुन्हा दाखवणारा cart monotonic reads मोडतो. आपले profile save करून जुनेच profile पाहणारी user read-your-writes मोडलेले पाहते. दोनदा book झालेली seat linearizability मोडते. प्रत्येक data च्या तुकड्याला कोणते वचन हवे ते नाव द्या, आणि मजबूत वचनांची किंमत फक्त जिथे महत्त्वाचे आहे तिथेच मोजा.

🔧 कसे (या repo मध्ये)

dist/demo.py मधले models() "exam कोणत्या दिवशी आहे?" साठी पाच वचने print करते. Snippet धडा 06 मधले QuorumStore वापरतो, निवडलेल्या प्रतींकडून R = 1 reads सह: फक्त copy 0 पर्यंत पोहोचलेला एक write, मग copy 0 आणि copy 2 कडून reads. फक्त जिथे लिहिले तिथूनच वाचले तर read-your-writes मिळते; वेगवेगळ्या प्रतींकडून वाचले तर monotonic reads मोडते; repair सह R = 3 read सगळ्या प्रती एकत्र आणतो (convergence).

🧪 करून पाहा

python3 dist/demo.py models
python3 - <<'EOF'
import sys; sys.path.insert(0, "dist"); from sim import QuorumStore
s = QuorumStore(3); s.write(1, "Monday", 3)
s.write(2, "Tuesday", 1, reachable=[0])          # Dipika's change reached only copy 0
print("copies:", s.copies)
print("Dipika reads her own copy 0      →", s.read(1, order=[0], repair=False)[0], "(read-your-writes holds)")
print("Aishwarya reads copy 2           →", s.read(1, order=[2], repair=False)[0], "(eventual: stale for now)")
first  = s.read(1, order=[0], repair=False)[0]
second = s.read(1, order=[2], repair=False)[0]
print(f"Katrina reads copy 0, then copy 2 → {first} then {second} (monotonic reads broken: time went backwards)")
print("R=3 read of all copies           →", s.read(3, repair=True)[0], "· after repair:", s.copies)
EOF

✅ तपासा — तुम्हाला काय दिसायला हवे

models हे print करते:

── the same question — 'what is the exam day?' — under different promises:
   linearizable      every read sees the latest completed write, as if there were one copy
   sequential        everyone sees the same order, maybe a little late
   causal            if you saw the cause (the change notice), you will see its effect (the new timetable)
   read-your-writes  Dipika always sees the change SHE made, others may lag
   eventual          copies agree when writes stop — meanwhile anything goes
   stronger promises cost coordination (latency, availability) — pick per piece of data

तुमचा snippet हे print करतो:

copies: [(2, 'Tuesday'), (1, 'Monday'), (1, 'Monday')]
Dipika reads her own copy 0      → Tuesday (read-your-writes holds)
Aishwarya reads copy 2           → Monday (eventual: stale for now)
Katrina reads copy 0, then copy 2 → Tuesday then Monday (monotonic reads broken: time went backwards)
R=3 read of all copies           → Tuesday · after repair: [(2, 'Tuesday'), (2, 'Tuesday'), (2, 'Tuesday')]

🏁 तुम्ही आत्ताच काय सिद्ध केले

त्याच तीन प्रतींनी तीन वेगवेगळे अनुभव दिले. दीपिकाला read-your-writes मिळाले ते फक्त तिने ज्या प्रतीवर लिहिले तीच वाचल्यामुळे — ही एक session युक्ती आहे, store चा गुणधर्म नाही. कतरिनाला वेळ मागे जाताना दिसली कारण तिचे दोन reads दोन वेगवेगळ्या प्रतींकडे गेले. आणि store तरीही "eventually consistent" होता: repair सह एका पूर्ण read ने सगळ्या प्रती जुळवल्या.

⚠️ नेहमीच्या चुका

कोणता model ते न सांगता "consistent" म्हणणे
एका user चे reads वेगवेगळा lag असलेल्या replicas मध्ये load-balance करणे (monotonic reads मोडते)
write नंतर लगेच replica कडून वाचणे (read-your-writes मोडते)
जिथे eventual पुरेसे आहे अशा data साठी (likes, view counts) linearizable reads ची किंमत मोजणे
setting च्या नावात "strong" आहे म्हणून store linearizable आहे असे मानणे — ते काय वचन देते ते वाचा

🏭 प्रत्यक्ष वापरात

Amazon DynamoDB — reads default नुसार eventually consistent असतात. Strongly consistent read त्याच्या आधी यशस्वी झालेल्या प्रत्येक write चा परिणाम परत देतो. On a real account:

aws dynamodb get-item --table-name notices \
    --key '{"id": {"S": "exam"}}' --consistent-read

Strongly consistent read ला eventually consistent read च्या दुप्पट read capacity लागते, आणि ते global secondary indexes वर उपलब्ध नाही. query आणि scan सुद्धा --consistent-read घेतात.

PostgreSQL replicas सह read-your-writes — user ने लिहिल्यानंतर, थोड्या वेळासाठी तिचे reads primary कडे पाठवा; किंवा तिच्या write नंतर primary ची WAL position लक्षात ठेवा आणि replica ने तिथपर्यंत replay केल्यावरच त्या replica कडून वाचा:

-- on the primary, after the write:
SELECT pg_current_wal_lsn();          -- for example 0/3000148, kept in her session
-- on a replica, before reading:
SELECT pg_last_wal_replay_lsn() >= '0/3000148'::pg_lsn;   -- true → safe to read here

Monotonic reads — एका user चे reads एकाच replica ला "sticky" करा (उदाहरणार्थ, user ID च्या hash ने replica निवडा), म्हणजे ती कधीच जास्त मागे असलेल्या प्रतीकडे उडी मारत नाही.

Linearizable reads — etcd reads default नुसार linearizable असतात (leader आधी खात्री करतो की तो अजून leader आहे); etcdctl get --consistency=s local member कडून जलद, कदाचित जुना serializable read मागते. QUORUM reads आणि writes सह Cassandra सर्वात नव्या value चे reads देते (धडा 06), पण पूर्ण linearizability नाही; त्यासाठी त्याचे lightweight transactions (INSERT ... IF NOT EXISTS) Paxos वापरतात.

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: तुमच्या data चे एक table बनवा — balances, seats, profiles, carts, counters — आणि प्रत्येकाला चालू शकेल असा सर्वात कमकुवत model लिहा. मग store आणि read path तो खरोखर देतात का ते तपासा.

⏭️ पुढे

मजबूत models साठी प्रतींना एकमेकांशी बोलावे लागते. त्यांच्यामधला रस्ता तुटला तर? मग तुम्हाला निवडावे लागते: नकार द्यायचा, की कदाचित जुने असलेले काहीतरी उत्तर द्यायचे. CAP आणि PACELC.

git checkout lesson-08-cap-pacelc

📏 Lesson 07 — Consistency models: what each one promises the reader

📍 You are here: Lesson 07 of 12 · Previous: lesson-06-quorums · Next: lesson-08-cap-pacelc

📦 What's in this branch

Lessons 01–06, plus the names for what a reader is promised when data has copies: linearizable, sequential, causal, read-your-writes, monotonic reads and eventual consistency — from strongest to weakest — and what each one costs. models() in dist/demo.py lists them; the snippet below breaks two of them on purpose with QuorumStore from lesson 06.

🧒 Explain like I'm 5

Everyone asks the same question: "What is the exam day?" The branches can make different promises about the answer.

🥇 "As if there were one register." Once anyone has seen "Tuesday", nobody anywhere will ever see "Monday" again. (linearizable)
🥈 "Everyone sees the changes in the same order." Maybe a little late, but never in a different order. (sequential)
🥉 "Cause before effect." If you saw the notice "the exam is moved", you will also see the new timetable it talks about. (causal)
🙋 "You see your own change." Dipika changed the notice, so Dipika always sees her change. Others may still see the old one. (read-your-writes)
⏩ "Never back in time." Once Katrina saw Tuesday, she will not later see Monday. (monotonic reads)
🌫️ "In the end, everyone agrees." If people stop changing it, all copies will match — some day. Until then, anything goes. (eventual)

Stronger promises are nicer. They also cost more waiting and more messengers.

🗺️ Diagram

flowchart TB
    lin["🥇 linearizable<br/>one copy, real-time order"] --> seq["🥈 sequential<br/>one order for all, maybe late"]
    seq --> cau["🥉 causal<br/>cause before effect"]
    cau --> ryw["🙋 read-your-writes<br/>you see your own change"]
    cau --> mr["⏩ monotonic reads<br/>never back in time"]
    ryw --> ev["🌫️ eventual<br/>copies agree when writes stop"]
    mr --> ev
    cost["⬆️ stronger = more coordination<br/>more latency, less availability"]

🗺️ Drawn version + a lab: https://school-edh.pages.dev/distributed-systems/lesson-diagrams.html#l07

❓ What

Consistency model — a contract between the data store and its readers: which values a read is allowed to return, given the writes that happened.
Linearizable (strong consistency, "atomic") — every operation appears to happen at one instant between its start and its end, in an order that matches real time. Once a write completes, every later read (by anyone) sees it or something newer. It behaves as if there were one copy. This is the "C" in CAP (lesson 08).
Sequential — all nodes see all operations in one order, and each client's own operations appear in the order that client did them. Unlike linearizable, that order does not have to match real time: a read may be a little behind.
Causal — operations that are causally related (lesson 03) are seen by everyone in that order. Concurrent operations may be seen in different orders by different nodes. It is the strongest model that can stay available during a network partition.
Read-your-writes (read-your-own-writes) — a client always sees its own earlier writes. Other clients may not yet.
Monotonic reads — a client never sees an older value after a newer one. Commonly broken when one user's reads go to different replicas with different lag.
Eventual — if writes stop, all copies eventually converge to the same value. No promise about when, and no promise about what a read returns meanwhile.
Session guarantees — read-your-writes, monotonic reads (and two others: monotonic writes, writes-follow-reads) are promises per client session; they are cheap to add on top of eventual consistency, for example by sending one user's reads to one replica.

🤔 Why

Because "consistent" means different things to different people, and bugs live in the difference. A cart that shows an item, then hides it, then shows it again breaks monotonic reads. A user who saves her profile and sees the old one breaks read-your-writes. A double-booked seat breaks linearizability. Name the promise each piece of data needs, and pay for the strong ones only where they matter.

🔧 How (in this repo)

models() in dist/demo.py prints the five promises for "what is the exam day?". The snippet uses QuorumStore from lesson 06 with R = 1 reads from chosen copies: a write that reached only copy 0, then reads from copy 0 and copy 2. Reading only where you wrote gives read-your-writes; reading from different copies breaks monotonic reads; an R = 3 read with repair brings all copies together (convergence).

🧪 Try it

python3 dist/demo.py models
python3 - <<'EOF'
import sys; sys.path.insert(0, "dist"); from sim import QuorumStore
s = QuorumStore(3); s.write(1, "Monday", 3)
s.write(2, "Tuesday", 1, reachable=[0])          # Dipika's change reached only copy 0
print("copies:", s.copies)
print("Dipika reads her own copy 0      →", s.read(1, order=[0], repair=False)[0], "(read-your-writes holds)")
print("Aishwarya reads copy 2           →", s.read(1, order=[2], repair=False)[0], "(eventual: stale for now)")
first  = s.read(1, order=[0], repair=False)[0]
second = s.read(1, order=[2], repair=False)[0]
print(f"Katrina reads copy 0, then copy 2 → {first} then {second} (monotonic reads broken: time went backwards)")
print("R=3 read of all copies           →", s.read(3, repair=True)[0], "· after repair:", s.copies)
EOF

✅ Verify — what you should see

models prints:

── the same question — 'what is the exam day?' — under different promises:
   linearizable      every read sees the latest completed write, as if there were one copy
   sequential        everyone sees the same order, maybe a little late
   causal            if you saw the cause (the change notice), you will see its effect (the new timetable)
   read-your-writes  Dipika always sees the change SHE made, others may lag
   eventual          copies agree when writes stop — meanwhile anything goes
   stronger promises cost coordination (latency, availability) — pick per piece of data

Your snippet prints:

copies: [(2, 'Tuesday'), (1, 'Monday'), (1, 'Monday')]
Dipika reads her own copy 0      → Tuesday (read-your-writes holds)
Aishwarya reads copy 2           → Monday (eventual: stale for now)
Katrina reads copy 0, then copy 2 → Tuesday then Monday (monotonic reads broken: time went backwards)
R=3 read of all copies           → Tuesday · after repair: [(2, 'Tuesday'), (2, 'Tuesday'), (2, 'Tuesday')]

🏁 What you just proved

The same three copies gave three different experiences. Dipika got read-your-writes only because she read the copy she wrote to — a session trick, not a property of the store. Katrina saw time go backwards because her two reads went to two different copies. And the store was still "eventually consistent": one full read with repair made all copies agree.

⚠️ Common mistakes

saying "consistent" without saying which model
load-balancing one user's reads across replicas with different lag (breaks monotonic reads)
reading from a replica right after a write (breaks read-your-writes)
paying for linearizable reads on data where eventual is fine (likes, view counts)
assuming a store is linearizable because it has "strong" in a setting name — read what it promises

🏭 In production

Amazon DynamoDB — reads are eventually consistent by default. A strongly consistent read returns the result of every write that succeeded before it. On a real account:

aws dynamodb get-item --table-name notices \
    --key '{"id": {"S": "exam"}}' --consistent-read

A strongly consistent read costs twice the read capacity of an eventually consistent one, and it is not available on global secondary indexes. query and scan take --consistent-read too.

Read-your-writes with PostgreSQL replicas — after a user writes, send her reads to the primary for a short time; or remember the primary's WAL position after her write and read from a replica only once it has replayed that far:

-- on the primary, after the write:
SELECT pg_current_wal_lsn();          -- for example 0/3000148, kept in her session
-- on a replica, before reading:
SELECT pg_last_wal_replay_lsn() >= '0/3000148'::pg_lsn;   -- true → safe to read here

Monotonic reads — make one user's reads "sticky" to one replica (for example, choose the replica by a hash of the user ID), so she never jumps to a copy that is further behind.

Linearizable reads — etcd reads are linearizable by default (the leader confirms it is still leader first); etcdctl get --consistency=s asks for a faster, possibly stale serializable read from the local member. Cassandra with QUORUM reads and writes gives newest-value reads (lesson 06), but not full linearizability; its lightweight transactions (INSERT ... IF NOT EXISTS) use Paxos for that.

🏭 Why this matters in production: make a table of your data — balances, seats, profiles, carts, counters — and write the weakest model each one can live with. Then check that the store and the read path actually give it.

⏭️ Next

Stronger models need the copies to talk. What if the road between them is cut? Then you must choose: refuse, or answer something possibly stale. CAP and PACELC.

git checkout lesson-08-cap-pacelc

← Previousquorums Next →cap pacelc

This page is the lesson's README from the lesson-07-consistency-models branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.