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

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

🔁 धडा 10 — Consistency: सूचना-नोंदवहीच्या तीन प्रती

📍 तुम्ही इथे आहात: 18 पैकी धडा 10 · पुढील: lesson-11-distributed-transactions

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

धडे 01–09, आणि प्रत्येक प्रत उभा करणारा प्रश्न: data एकापेक्षा जास्त ठिकाणी राहतो तेव्हा कोणती प्रत खरे सांगते? तुम्ही शिकता strong आणि eventual consistency, replicas आणि replication lag, quorums (R + W > N), read-your-writes, monotonic reads, सोप्या शब्दांत CAP आणि PACELC, आणि data च्या प्रत्येक प्रकारासाठी निवड कशी करायची.

design/blocks.py — quorum_ok(n, r, w) आणि quorum_read(copies, r)
design/demo.py — python3 design/demo.py consistency
design/test_design.py — check L10
demo-output.txt — निरोगी run काय छापतो

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

दीपिकाचे नियोजन कार्यालय सूचना-नोंदवही तीन शिक्षक-खोल्यांत ठेवते, म्हणजे एक खोली कुलूपबंद असली तरी सगळ्यांचे काम थांबत नाही.

कतरिना एक सूचना बदलते: "परीक्षा मंगळवारी हलवली." ती हे खोली 1 मधील नोंदवहीत लिहिते. मग एक धावपटू हा बदल खोली 2 आणि 3 मध्ये घेऊन जातो. धावपटूला थोडा वेळ लागतो.

ऐश्वर्या खोली 3 मध्ये आहे. ती धावपटू पोहोचण्याआधी नोंदवही वाचते. तिला "सोमवार" दिसतो. काहीही तुटलेले नाही. तिची प्रत फक्त उशिराची आहे.

दीपिका एक नियम करते: "झाले म्हणण्याआधी बदल दोन नोंदवह्यांत लिहा. दोन नोंदवह्या वाचा आणि जास्त पान-क्रमांक असलेले पान ठेवा." दोन लिहिलेल्या अधिक दोन वाचलेल्या नोंदवह्या म्हणजे चार — तीन खोल्यांपेक्षा जास्त. म्हणून दोन्ही गटांत नेहमी एक खोली सामाईक असते, आणि वाचणारीला नेहमी नवे पान सापडते.

एके दिवशी मार्गिका अडते. खोली 3 बाकीच्यांपर्यंत पोहोचू शकत नाही. एक पालक खोली 3 ला विचारतो. खोली 3 कडे दोन पर्याय असतात: जे आहे ते उत्तर द्यायचे (कदाचित जुने), किंवा "कृपया थांबा" म्हणायचे (बरोबर राहायचे). दोन्ही एकदम करता येत नाही. हीच निवड म्हणजे CAP.

🗺️ आकृती

flowchart LR
    w["✍️ Katrina writes v8<br/>exam moved to Tuesday"]
    subgraph n3["📚 N = 3 copies"]
      c1["room 1 · v8"]
      c2["room 2 · v8"]
      c3["room 3 · v7 · lag"]
    end
    w -->|"W = 2: wait for 2 copies"| c1
    w -->|"W = 2"| c2
    w -.->|"later"| c3
    r["👀 Aishwarya reads<br/>R = 2, keep the newest"]
    r --> c2
    r --> c3
    ok["2 + 2 > 3 → the groups overlap<br/>she sees v8"]
    r --> ok

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

❓ काय

Replica — दुसऱ्या server वरची data ची पूर्ण प्रत. Replicas मुळे जास्त वाचक सांभाळता येतात, आणि एक server गेला तरी system टिकते.
Replication lag — एका प्रतीवर write झाल्यापासून तो बाकीच्या प्रतींवर पोहोचेपर्यंतचा वेळ. सहसा milliseconds. Load असताना, किंवा regions ओलांडून, तो seconds किंवा त्याहून जास्त असू शकतो.
Strong consistency — प्रत्येक read नवीनतम पूर्ण झालेला write पाहतो. जणू एकच प्रत आहे असे वाटते.
Eventual consistency — writes थांबले तर सगळ्या प्रती शेवटी सारख्या होतात. तोपर्यंत एखादा read जुनी value देऊ शकतो.
Quorum — N प्रती असताना, write त्यांपैकी W ची वाट पाहतो, आणि read R प्रतींना विचारतो आणि सर्वात नवी version ठेवतो. R + W > N असेल, तर प्रत्येक read गटात प्रत्येक write गटाशी किमान एक प्रत सामाईक असते, म्हणून read ला नवीनतम write दिसतो. N = 3 सह R = 2 आणि W = 2 ही नेहमीची निवड. त्यात एक प्रत गेली तरी system टिकते.
Read-your-writes — तुम्ही काही बदलल्यावर तुम्हाला तुमचा बदल दिसतो. इतर वाचकांना क्षणभर जुनी value दिसू शकते. हे मिळवण्याचे मार्ग: स्वतःच्या write नंतर काही seconds primary वरून read करा, किंवा तुम्ही लिहिलेली version लक्षात ठेवा आणि ती असलेल्या प्रतीवरूनच read करा.
Monotonic reads — वाचणारी कधी काळात मागे जात नाही: "मंगळवार" पाहिल्यावर तिला पुन्हा "सोमवार" दिसता कामा नये. हे मिळवण्याचा मार्ग: एका वाचकाला त्याच replica वर ठेवा (sticky), किंवा तिने शेवटची पाहिलेली version लक्षात ठेवा.
CAP — network split (Partition) च्या वेळी, बाकीच्यांपर्यंत पोहोचू न शकणाऱ्या प्रतीला निवड करावी लागते: Consistent राहायचे (नकार द्यायचा किंवा थांबायचे) की Available राहायचे (उत्तर द्यायचे, कदाचित जुने). Splits होतातच, म्हणून खरी निवड split च्या वेळी C आणि A मध्ये असते.
PACELC — उरलेली गोष्ट: Partition असेल तर A किंवा C निवडा; Else (सामान्य दिवशी), Latency किंवा Consistency निवडा. जास्त प्रतींची वाट पाहणे हळू असते. ही निवड तुम्ही दररोज करता, फक्त split च्या वेळी नाही.

🤔 का

कारण धडे 05–09 ने सगळीकडे प्रती तयार केल्या: caches, read replicas, इतर services update करणारे events. प्रत्येक प्रत उशिराची असू शकते. नियोजन कार्यालयाने data च्या प्रत्येक प्रकारासाठी ठरवले पाहिजे की किती उशीर चालतो. एका दिशेने चूक झाली, तर पालक fee दोनदा भरतो. दुसऱ्या दिशेने चूक झाली, तर पूर्ण app एका view counter साठी थांबतो.

सूचना फलक, प्रत्येक data प्रकारासाठी ठरवलेले:

data	निवड	का
fee payments	strong	पैसे कधीही दोनदा मोजले जाऊ नयेत किंवा हरवू नयेत
गुण	strong	दुरुस्तीनंतर पालकाला जुना गुण दिसता कामा नये
कोण कोणत्या वर्गात आहे (access)	strong	काढलेल्या पालकाचा access लगेच गेला पाहिजे
सूचना, तिच्या लेखिकेसाठी	read-your-writes	"posted" नंतर कतरिनाला तिची स्वतःची post दिसली पाहिजे
सूचना, इतर पालकांसाठी	eventual (seconds)	काही seconds उशीर चालतो
"312 पालकांनी वाचली" counters, likes	eventual	2 seconds जुन्या आकड्याने कोणाचे नुकसान होत नाही

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

design/blocks.py मधील quorum_ok(n, r, w) r + w > n परत करतो. quorum_read(copies, r) (version, value) प्रतींची यादी घेतो, त्यांपैकी पहिल्या r वाचतो आणि सर्वात मोठी version ठेवतो. design/demo.py मधील consistency() N = 3 साठी चार R/W जोड्या वापरून पाहतो, मग अशा तीन प्रती वाचतो ज्यांपैकी फक्त एकीकडे नवी version 8 आहे.

🧪 करून पाहा

python3 design/demo.py consistency
python3 - <<'EOF'
import sys; sys.path.insert(0, "design"); from blocks import quorum_ok, quorum_read
for n in (3, 5):
    strong = [f"R={r} W={w}" for r in range(1, n + 1) for w in range(1, n + 1) if quorum_ok(n, r, w)]
    print(f"N={n}: {len(strong)} of {n * n} choices are strong · smallest pair with R = W: R=W={n // 2 + 1}")
copies = [(8, "exam moved to Tuesday"), (7, "exam on Monday"), (7, "exam on Monday")]
print("W=1 (only copy 1 has v8):", "R=1 from copy 3 →", quorum_read(copies[2:], 1)[1], "· R=2 from copies 2,3 →", quorum_read(copies[1:], 2)[1])
copies = [(8, "exam moved to Tuesday"), (8, "exam moved to Tuesday"), (7, "exam on Monday")]
print("W=2 (copies 1,2 have v8):", "R=2 from copies 2,3 →", quorum_read(copies[1:], 2)[1], "· R=2 from copies 1,3 →", quorum_read(copies[::2], 2)[1])
EOF
python3 design/test_design.py

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

consistency हे छापतो:

── 3 copies (N=3): which read/write sizes are sure to see the latest write? (R + W > N)
   R=1 W=1 → eventual: may read a stale copy
   R=1 W=3 → strong: overlaps
   R=2 W=2 → strong: overlaps
   R=3 W=1 → strong: overlaps
   copies [(7, 'exam on Monday'), (8, 'exam moved to Tuesday'), (7, 'exam on Monday')] · read R=1 → 'exam on Monday' · read R=2 → 'exam moved to Tuesday'
   CAP: during a network split you choose — answer (maybe stale) or refuse (stay correct)
   most apps: strong for money and grades, eventual for likes and view counts

तुमचा snippet हे छापतो:

N=3: 6 of 9 choices are strong · smallest pair with R = W: R=W=2
N=5: 15 of 25 choices are strong · smallest pair with R = W: R=W=3
W=1 (only copy 1 has v8): R=1 from copy 3 → exam on Monday · R=2 from copies 2,3 → exam on Monday
W=2 (copies 1,2 have v8): R=2 from copies 2,3 → exam moved to Tuesday · R=2 from copies 1,3 → exam moved to Tuesday

Tests मध्ये ✅ L10 R + W > N overlaps; R=1 W=1 does not असते आणि शेवटी 18/18 passed येते.

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

3 प्रती असताना 9 पैकी 6 R/W जोड्या strong असतात; 5 प्रती असताना सर्वात लहान समान जोडी R = W = 3 — म्हणजे बहुमत. Demo मधील R = 2 read नीट पाहा: त्याला "Tuesday" सापडले, पण फक्त एकाच प्रतीकडे version 8 होती (W = 1), आणि 2 + 1 हे 3 पेक्षा जास्त नाही. Demo ने प्रती 1 आणि 2 वाचल्या आणि ते नशिबाने बरोबर आले. तुमच्या snippet ने प्रती 2 आणि 3 वाचल्या आणि "Monday" मिळाले. W = 2 असताना दोन प्रतींची प्रत्येक जोडी "Tuesday" शोधते. Quorum म्हणजे "जास्त प्रती वाचा" नव्हे. ते म्हणजे "read गट आणि write गट एकमेकांना छेदतील असे करा".

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

write नंतर लगेच replica वरून read करणे, आणि मग लेखकाला जुनी value दाखवणे ("मी post केले, ते कुठे आहे?") — read-your-writes वापरा
एकाच पालकाला प्रत्येक page वर वेगळ्या replica कडे पाठवणारा load balancer — सूचना दिसते, गायब होते आणि पुन्हा दिसते (monotonic reads नाहीत)
सगळ्यासाठी strong consistency निवडणे — प्रत्येक write सर्वात हळू प्रतीची वाट पाहतो
पैसे, गुण किंवा access rights साठी eventual consistency निवडणे
कागदावर R + W > N, पण "sloppy" quorums किंवा hinted handoff चालू, जे अपयशाच्या वेळी इतर nodes वर लिहितात — database च्या बारीक अटी वाचा
सामान्य दिवशी CAP म्हणजे "तीनपैकी दोन निवडा" असे समजणे — निवड फक्त split च्या वेळी असते; सामान्य दिवशी देवाणघेवाण latency विरुद्ध consistency अशी असते (PACELC)

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

खऱ्या account वर — DynamoDB reads default ने eventually consistent असतात. Strongly consistent read मागा (त्याला दुप्पट read capacity लागते, आणि global tables चे स्वतःचे नियम असतात):

aws dynamodb get-item --table-name notices \
    --key '{"class_id":{"S":"3A"},"created_at":{"S":"2026-09-27T09:00:00Z"}}' \
    --consistent-read

Cassandra: प्रत्येक query साठी level ठरवा. Read आणि write दोन्हीसाठी QUORUM दिल्यास R + W > N मिळते:

CONSISTENCY QUORUM;
SELECT * FROM notices WHERE class_id = '3A' LIMIT 20;

Synchronous replicas सह PostgreSQL: commit तोपर्यंत थांबतो जोपर्यंत दोनपैकी एका standby कडे तो पोहोचत नाही (primary वरील postgresql.conf):

synchronous_standby_names = 'ANY 1 (standby_a, standby_b)'
synchronous_commit = on

App मध्ये read-your-writes: पालक किंवा शिक्षिकेने लिहिल्यावर, काही seconds तिचे reads primary कडे पाठवा:

def db_for_read(session):
    if time.time() - session.get("last_write_at", 0) < 5:   # 5 s > the usual replica lag
        return PRIMARY
    return REPLICA

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: प्रत्येक design च्या data table मध्ये एक "consistency" column ठेवा: strong, read-your-writes किंवा eventual — आणि का याची एक ओळ. मग replica lag वर alarm लावा (उदाहरणार्थ RDS read replicas साठी CloudWatch मधील ReplicaLag), कारण "eventual" तोपर्यंतच चालते जोपर्यंत "eventual" कमी वेळाचे आहे.

⏭️ पुढे

प्रती असलेली एक service आता स्पष्ट झाली. पण शाळेच्या सहलीचे booking तीन services ना स्पर्श करते: seats, payment आणि bus. तिसरी नाही म्हणाली तर? Services ओलांडून transactions.

git checkout lesson-11-distributed-transactions

🔁 Lesson 10 — Consistency: three copies of the notice book

📍 You are here: Lesson 10 of 18 · Next: lesson-11-distributed-transactions

📦 What's in this branch

Lessons 01–09, plus the question every copy raises: when the data lives in more than one place, which copy tells the truth? You learn strong and eventual consistency, replicas and replication lag, quorums (R + W > N), read-your-writes, monotonic reads, CAP and PACELC in plain words, and how to choose per kind of data.

design/blocks.py — quorum_ok(n, r, w) and quorum_read(copies, r)
design/demo.py — python3 design/demo.py consistency
design/test_design.py — check L10
demo-output.txt — what a healthy run prints

🧒 Explain like I'm 5

Dipika's planning office keeps the notice book in three staff rooms, so that one locked room does not stop everyone.

Katrina changes a notice: "The exam moves to Tuesday." She writes it in the book of room 1. A runner then carries the change to rooms 2 and 3. The runner takes a little time.

Aishwarya is in room 3. She reads the book before the runner arrives. She sees "Monday". Nothing is broken. Her copy is only late.

Dipika makes a rule: "Write the change in two books before you say done. Read two books and keep the page with the higher page number." Two books written plus two books read is four — more than three rooms. So the two groups always share a room, and the reader always finds the new page.

One day the corridor is blocked. Room 3 cannot reach the others. A parent asks room 3. Room 3 has two choices: answer with what it has (maybe old), or say "please wait" (stay correct). It cannot do both. That choice is CAP.

🗺️ Diagram

flowchart LR
    w["✍️ Katrina writes v8<br/>exam moved to Tuesday"]
    subgraph n3["📚 N = 3 copies"]
      c1["room 1 · v8"]
      c2["room 2 · v8"]
      c3["room 3 · v7 · lag"]
    end
    w -->|"W = 2: wait for 2 copies"| c1
    w -->|"W = 2"| c2
    w -.->|"later"| c3
    r["👀 Aishwarya reads<br/>R = 2, keep the newest"]
    r --> c2
    r --> c3
    ok["2 + 2 > 3 → the groups overlap<br/>she sees v8"]
    r --> ok

🗺️ Drawn version + a lab: https://school-edh.pages.dev/system-design/lesson-diagrams.html#l10

❓ What

Replica — a full copy of the data on another server. Replicas give more readers, and survival when one server is lost.
Replication lag — the time between a write on one copy and its arrival on the others. Usually milliseconds. Under load, or across regions, it can be seconds or more.
Strong consistency — every read sees the latest finished write. It feels like one copy.
Eventual consistency — if the writes stop, all copies become equal in the end. Until then, a read may return an older value.
Quorum — with N copies, a write waits for W of them, and a read asks R of them and keeps the newest version. If R + W > N, every read group shares at least one copy with every write group, so the read sees the latest write. With N = 3, R = 2 and W = 2 is the usual choice. It also survives the loss of one copy.
Read-your-writes — after you change something, you see your change. Other readers may still see the old value for a moment. Ways to get it: read from the primary for a few seconds after your own write, or remember the version you wrote and read only from a copy that has it.
Monotonic reads — a reader never goes back in time: after she sees "Tuesday", she must not see "Monday" again. Way to get it: keep one reader on the same replica (sticky), or remember the version she last saw.
CAP — during a network split (a Partition), a copy that cannot reach the others must choose: stay Consistent (refuse or wait) or stay Available (answer, maybe stale). Splits happen, so the real choice is between C and A during a split.
PACELC — the rest of the story: if there is a Partition, choose A or C; Else (normal days), choose Latency or Consistency. Waiting for more copies is slower. This is the choice you make every day, not only during a split.

🤔 Why

Because lessons 05–09 made copies everywhere: caches, read replicas, events that update other services. Every copy can be late. The planning office must decide, per kind of data, how late is acceptable. Wrong in one direction, a parent pays a fee twice. Wrong in the other direction, the whole app waits for a view counter.

The notice board, decided per data type:

data	choice	why
fee payments	strong	money must never be counted twice or lost
grades	strong	a parent must not see an old grade after a correction
who belongs to which class (access)	strong	a removed parent must lose access at once
a notice, for its author	read-your-writes	Katrina must see her own post after "posted"
a notice, for other parents	eventual (seconds)	a few seconds late is fine
"read by 312 parents" counters, likes	eventual	nobody is harmed by a count that is 2 seconds old

🔧 How (in this repo)

quorum_ok(n, r, w) in design/blocks.py returns r + w > n. quorum_read(copies, r) takes a list of (version, value) copies, reads the first r of them and keeps the highest version. consistency() in design/demo.py tries four R/W pairs for N = 3, then reads three copies where only one has the new version 8.

🧪 Try it

python3 design/demo.py consistency
python3 - <<'EOF'
import sys; sys.path.insert(0, "design"); from blocks import quorum_ok, quorum_read
for n in (3, 5):
    strong = [f"R={r} W={w}" for r in range(1, n + 1) for w in range(1, n + 1) if quorum_ok(n, r, w)]
    print(f"N={n}: {len(strong)} of {n * n} choices are strong · smallest pair with R = W: R=W={n // 2 + 1}")
copies = [(8, "exam moved to Tuesday"), (7, "exam on Monday"), (7, "exam on Monday")]
print("W=1 (only copy 1 has v8):", "R=1 from copy 3 →", quorum_read(copies[2:], 1)[1], "· R=2 from copies 2,3 →", quorum_read(copies[1:], 2)[1])
copies = [(8, "exam moved to Tuesday"), (8, "exam moved to Tuesday"), (7, "exam on Monday")]
print("W=2 (copies 1,2 have v8):", "R=2 from copies 2,3 →", quorum_read(copies[1:], 2)[1], "· R=2 from copies 1,3 →", quorum_read(copies[::2], 2)[1])
EOF
python3 design/test_design.py

✅ Verify — what you should see

consistency prints:

── 3 copies (N=3): which read/write sizes are sure to see the latest write? (R + W > N)
   R=1 W=1 → eventual: may read a stale copy
   R=1 W=3 → strong: overlaps
   R=2 W=2 → strong: overlaps
   R=3 W=1 → strong: overlaps
   copies [(7, 'exam on Monday'), (8, 'exam moved to Tuesday'), (7, 'exam on Monday')] · read R=1 → 'exam on Monday' · read R=2 → 'exam moved to Tuesday'
   CAP: during a network split you choose — answer (maybe stale) or refuse (stay correct)
   most apps: strong for money and grades, eventual for likes and view counts

Your snippet prints:

N=3: 6 of 9 choices are strong · smallest pair with R = W: R=W=2
N=5: 15 of 25 choices are strong · smallest pair with R = W: R=W=3
W=1 (only copy 1 has v8): R=1 from copy 3 → exam on Monday · R=2 from copies 2,3 → exam on Monday
W=2 (copies 1,2 have v8): R=2 from copies 2,3 → exam moved to Tuesday · R=2 from copies 1,3 → exam moved to Tuesday

The tests include ✅ L10 R + W > N overlaps; R=1 W=1 does not and end with 18/18 passed.

🏁 What you just proved

With 3 copies, 6 of the 9 R/W pairs are strong; with 5 copies the smallest equal pair is R = W = 3 — a majority. Look closely at the demo's R = 2 read: it found "Tuesday", but only one copy had version 8 (W = 1), and 2 + 1 is not more than 3. The demo read copies 1 and 2 and was lucky. Your snippet read copies 2 and 3 and got "Monday". With W = 2, every pair of two copies finds "Tuesday". A quorum is not "read more copies". It is "make the read group and the write group overlap".

⚠️ Common mistakes

reading from a replica right after a write, then showing the author the old value ("I posted it, where is it?") — use read-your-writes
a load balancer that sends one parent to a different replica on every page — the notice appears, disappears and appears again (no monotonic reads)
choosing strong consistency for everything — every write waits for the slowest copy
choosing eventual consistency for money, grades or access rights
R + W > N on paper, but "sloppy" quorums or hinted handoff turned on, which write to other nodes during a failure — read the database's fine print
thinking CAP means "pick two of three" on a normal day — the choice exists only during a split; on normal days the trade is latency against consistency (PACELC)

🏭 In production

On a real account — DynamoDB reads are eventually consistent by default. Ask for a strongly consistent read (it costs twice the read capacity, and global tables add their own rules):

aws dynamodb get-item --table-name notices \
    --key '{"class_id":{"S":"3A"},"created_at":{"S":"2026-09-27T09:00:00Z"}}' \
    --consistent-read

Cassandra: set the level per query. QUORUM for both read and write gives R + W > N:

CONSISTENCY QUORUM;
SELECT * FROM notices WHERE class_id = '3A' LIMIT 20;

PostgreSQL with synchronous replicas: a commit waits until one of two standbys has it (postgresql.conf on the primary):

synchronous_standby_names = 'ANY 1 (standby_a, standby_b)'
synchronous_commit = on

Read-your-writes in the app: after a parent or a teacher writes, send her reads to the primary for a few seconds:

def db_for_read(session):
    if time.time() - session.get("last_write_at", 0) < 5:   # 5 s > the usual replica lag
        return PRIMARY
    return REPLICA

🏭 Why this matters in production: put a "consistency" column in the data table of every design: strong, read-your-writes or eventual — and one line of why. Then alarm on replica lag (for example ReplicaLag in CloudWatch for RDS read replicas), because "eventual" is only acceptable while "eventual" is short.

⏭️ Next

One service with copies is now clear. But a school trip booking touches three services: seats, payment and the bus. What if the third one says no? Transactions across services.

git checkout lesson-11-distributed-transactions

← Previousservices Next →distributed transactions

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