🌐 शाळेच्या पद्धतीने distributed systems शिका

# the 60-second wow — four branches, one register:
git clone https://github.com/BaluRaut/learn-distributed-systems-school.git && cd learn-distributed-systems-school
python3 dist/demo.py               # 12 lessons: lost notes, split roads, elections, fences
python3 dist/test_dist.py          # 12 checks across the lessons

तुम्हाला काय दिसायला हवे (छाटलेले — यश असे दिसते):

═══ failures ═══
── Pune sends 20 notes to Nashik by messenger (10% get lost, 5–50 ms each)
   arrived 18 of 20 · delays 5–48 ms · lost 2
   Pune sent 'is the exam at 10?' and heard nothing. Was the note lost? Is Nashik down? Is the answer lost? Just slow?
   from Pune these all look the SAME — that is partial failure, and it is the whole subject
   the fallacies: the network is reliable · latency is zero · bandwidth is infinite · the topology never changes

═══ clocks ═══
── wall clocks drift: Pune's clock reads 10:00:00.120, Nashik's reads 09:59:59.980 at the same instant
   Pune writes 'exam at 10' at 10:00:00.100 by its clock; Nashik then writes 'exam at 11' at 10:00:00.050 by its clock
   sorting by wall time says Pune's note was LAST — the later change is silently thrown away
── Lamport: Pune writes (L=1) → Nashik receives (L=2) → Nashik writes (L=3) — cause always has a smaller number
   Lamport numbers give an order everyone agrees on, but cannot say whether two events were independent

═══ ordering ═══
── vector clocks: e1 at Pune {'pune': 1, 'nashik': 0, 'nagpur': 0, 'kolhapur': 0}
   e2 at Nashik after reading e1 {'pune': 1, 'nashik': 1, 'nagpur': 0, 'kolhapur': 0}
   e3 at Nagpur, unaware of both {'pune': 0, 'nashik': 0, 'nagpur': 1, 'kolhapur': 0}
   e1 vs e2: before
   e2 vs e3: concurrent
   e1 vs e3: concurrent
   'concurrent' = nobody saw the other → a real conflict to resolve, not an order to pick

═══ detection ═══
── Kolhapur's heartbeats arrive with gaps (ms): [100, 110, 95, 340, 105, 120, 180, 95] — two slow moments (a GC pause, a busy network), then it really dies
   timeout 150 ms → false alarms while alive: 2 · the real death is noticed after 150 ms
   timeout 400 ms → false alarms while alive: 0 · the real death is noticed after 400 ms
   timeout 800 ms → false alarms while alive: 0 · the real death is noticed after 800 ms
   short timeout: fast but jumpy · long timeout: calm but slow · you cannot have both — tune, and make actions safe to repeat

═══ replication ═══
── asynchronous replication: 4 grades acknowledged, then Pune (leader) dies → new leader has ['g1', 'g2'], lost ['g3', 'g4']
── synchronous replication: 4 grades acknowledged, then Pune (leader) dies → new leader has ['g1', 'g2', 'g3', 'g4'], lost []
   async: fast writes, but acknowledged data can vanish on failover · sync: nothing lost, every write waits for a follower
   the common middle: one synchronous follower (semi-sync), the rest asynchronous

═══ quorums ═══
── 3 copies, the change reached only W=2 of them: [(2, 'exam moved to Tuesday'), (2, 'exam moved to Tuesday'), (1, 'exam on Monday')]
   read R=2 from copies 1 and 2 → 'exam moved to Tuesday' · copy [2] was stale and got repaired → [(2, 'exam moved to Tuesday'), (2, 'exam moved to Tuesday'), (2, 'exam moved to Tuesday')]
   R + W > N (2 + 2 > 3): every read quorum overlaps every write quorum, so the newest version is always seen
   anti-entropy (background repair) fixes copies nobody reads

═══ models ═══
── 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

═══ cap ═══
── the road between Pune+Nashik and Nagpur+Kolhapur is cut (a partition); Nagpur holds v1, the latest is v2
   CP: Nagpur is asked the exam day → refused — cannot reach a majority, so no answer rather than a wrong one
   AP: Nagpur is asked the exam day → answered v1 (stale!)
── both sides accepted a change during the split: (5, '3A trip on Friday') and (6, '3A trip on Saturday')
   last-writer-wins → '3A trip on Saturday' (the other write is silently dropped) · merge → ['3A trip on Friday', '3A trip on Saturday'] (a person decides)
   PACELC: during a Partition choose A or C; Else (normal days) choose Latency or Consistency

═══ raft ═══
── 5 branches run Raft; a leader needs a majority of ALL 5 (3 votes)
   term 1: nashik elected with 5/5 votes
   append 'exam on Tuesday', copied to pune + nagpur → committed — 3 of 5 with the leader
   append 'trip on Friday', copied to pune only   → not committed (no majority) — only 2 of 5
── the road splits: {nashik, pune} | {nagpur, kolhapur, satara}
   term 2: nashik got 2/5 — no majority, no leader
   term 3: nagpur elected with 3/5 votes
   the minority side cannot elect or commit — so there are never two leaders in the same term

═══ locks ═══
── Katrina takes the timetable lock, lease 1 s, fencing token 1 — then pauses for 2 s (a long GC)
   at 1.5 s the lease has expired; Aishwarya takes the lock → token 2 and writes → wrote 'timetable v2'
   Katrina wakes at 2.0 s, still thinks she holds the lock, writes with token 1 → refused token 1 (already saw 2)
   without fencing tokens → wrote 'timetable v1' — newer work silently overwritten
   a lease alone is not enough; the storage must check the token

═══ exactlyonce ═══
── the queue redelivers pay-dipika (at-least-once) · plain consumer      → effects ['pay-katrina', 'pay-dipika', 'pay-aishwarya', 'pay-dipika']
── the queue redelivers pay-dipika (at-least-once) · idempotent consumer  → effects ['pay-katrina', 'pay-dipika', 'pay-aishwarya']
   'exactly once' in the wire sense does not exist across a network; 'effectively once' = at-least-once + idempotency
   tools: idempotency keys, dedupe tables, upserts, the outbox, transactional reads-process-writes inside one system

═══ backpressure ═══
── 120 requests/s arrive, 100/s can be served · queue limit none → wait after 5 s 1.0 s, after 10 s 2.0 s · shed 0
── 120 requests/s arrive, 100/s can be served · queue limit  200 → wait after 5 s 1.0 s, after 10 s 1.0 s · shed 100
   an unbounded queue turns overload into ever-growing latency; a bounded one says 'try later' (429/503) early
── the whole picture: messengers fail → clocks disagree → copies drift → quorums and consensus agree → leases fence → keys dedupe → queues push back

✅ done — the branches agree

🗺️ संपूर्ण चित्र — एक आकृती, पूर्ण कोर्स

संपूर्ण कोर्स एका कॅनव्हासवर. 4K आवृत्तीसाठी क्लिक करा.

📨 भाग 1 — हे कठीण का आहे (धडे 1–4)

एक git branch = एक कल्पना; branch 04 मध्ये धडे 01–04 आहेत. dist/ चा प्रत्येक run सारखाच असतो — randomness seeded आहे.

📚 भाग 2 — प्रती (धडे 5–8)

एकाच data च्या अनेक प्रती ठेवणे: त्या कशा वेगळ्या होत जातात, quorums सर्वात नवीन कसे वाचतात, आणि partition भाग पाडते ती निवड.

👑 भाग 3 — एकमत (धडे 9–12)

अनेक machines ना एकमत करून सुरक्षितपणे वागायला लावणे: consensus, fencing, idempotency आणि backpressure.

📐 धड्यांच्या आकृत्या — क्रमांक अनुसरा

प्रत्येक धडा एका क्रमांकित बॉक्स-आणि-बाण आकृतीत — स्वतंत्र पानावरही.