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

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

📋 धडा 01 — गरजा आणि मर्यादा: नियोजन कार्यालय काढण्याआधी विचारते

📍 तुम्ही इथे आहात: 18 पैकी धडा 01 · पुढे: lesson-02-capacity

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

हा संपूर्ण कोर्स ज्या एका सवयीवर उभा आहे ती: एकही box काढण्याआधी, system ने काय करायचे, किती चांगले, आणि कोणत्या मर्यादेत — हे लिहून ठेवा. काम एका ओळीचे आहे — "5 million पालकांसाठी सूचना फलक app बनवा" — आणि या धड्यात ते चार भागांचा एक कागद बनते: functional गरजा, आकड्यांसह non-functional गरजा, मर्यादा (constraints) आणि कक्षेबाहेर (out of scope), सोबत काम देणाऱ्या व्यक्तीला विचारायचे प्रश्न. संपूर्ण कोर्सभर तुम्ही वापराल अशा खऱ्या files:

design/blocks.py — नियोजन कार्यालयाची हत्यारपेटी: अंदाज, hash ring, LRU cache, दोन rate limiters, quorums, 2PC आणि sagas, outbox, fan-out (144 ओळी, शून्य dependencies)
design/designs.py — कार्यपत्रके: pagination चा खर्च, store ची निवड, call chains, STRIDE, error budgets, पहिले बिल, ADRs आणि सहा सोडवलेल्या रचना (107 ओळी)
design/demo.py — प्रत्येक धडा एक छोटा program म्हणून (python3 design/demo.py <section>; sections: requirements capacity api data cache balance queues events services consistency transactions ratelimit resilience security observability cost designs1 designs2)
design/test_design.py — कार्यालयाच्या नियमांवरच्या 18 तपासण्या
demo-output.txt — निरोगी run काय छापतो

🎒 सुरू करण्याआधी: तुम्हाला फक्त Python 3 लागेल, बाकी काही नाही — cloud account नाही, pip install नाही. या files मध्ये गोल उदाहरणाच्या आकड्यांसह शिकवण्यासाठीचे models आहेत (प्रत्येक server ला सेकंदाला 500 requests, प्रत्येक सूचनेला 2 KB, 3× चा peak). अंकांपेक्षा पद्धत जास्त महत्त्वाची आहे. on a real account अशी खूण असलेल्या commands ना AWS CLI (किंवा Terraform, psql, …) आणि credentials लागतात, आणि त्यांचा खर्च येऊ शकतो.

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

शाळेला नवी इमारत हवी आहे. मुख्याध्यापिका कतरिना नियोजन कार्यालयात येते आणि म्हणते: "आम्हाला एक नवा हॉल हवा आहे."

नियोजन कार्यालय दीपिका चालवते. ती पेन्सिल उचलून लगेच चित्र काढायला सुरुवात करत नाही. ती एक फॉर्म 📋 उचलते आणि विचारते:

हॉलमध्ये काय होणार? परिपाठ? परीक्षा? खेळ? (काय करायचे)
किती मुले, आणि ती किती पटकन आत यायला हवीत? 5 मिनिटांत 600 मुले? (किती चांगले)
आपल्याकडे काय आहे? किती पैसे, किती जमीन, कोणते बांधकाम करणारे, कधीपर्यंत? (मर्यादा)
तो काय असणार नाही? जलतरण तलाव नाही. उपाहारगृह नाही. (कक्षेबाहेर)

60 मुलांसाठीचा हॉल आणि 6,000 मुलांसाठीचा हॉल या वेगवेगळ्या इमारती आहेत. दीपिकाने आधी काढले आणि नंतर विचारले, तर ती चुकीची इमारत काढेल — आणि भिंती उभ्या राहीपर्यंत कोणाच्याही लक्षात येणार नाही.

आपला "हॉल" म्हणजे एक app: एक सूचना फलक, जिथे शिक्षिका सूचना post करतात आणि 5 million पालक त्या वाचतात. नियोजन कार्यालय आधी फॉर्म भरते.

🗺️ आकृती

flowchart LR
    brief["📝 the brief<br/>'a notice board app<br/>for 5 million parents'"]
    q["❓ clarifying questions<br/>how many schools? peak time?<br/>data kept how long?"]
    subgraph sheet["📋 the requirements sheet"]
      f["✅ functional<br/>post · read · notify"]
      nf["📏 non-functional<br/>p99 < 200 ms · 99.9%<br/>100 reads : 1 post · never lost"]
      c["🧱 constraints<br/>team of 4 · AWS · Marathi + English<br/>few thousand $/month · 3 months"]
      o["🚫 out of scope<br/>chat · payments · video"]
    end
    next["🧮 lesson 02<br/>turn it into numbers"]
    brief --> q --> sheet --> next

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

❓ काय

System design — system चे भाग (boxes), ते एकमेकांशी कसे बोलतात (बाण), data कुठे राहतो आणि का, हे बहुतेक code लिहिण्याच्या आधी ठरवणे. याचे फलित म्हणजे एक आकृती आणि त्यामागची कारणे.
Functional गरजा — system काय करते, एखादी व्यक्ती करू शकेल अशा कृतींच्या रूपात लिहिलेले: "शिक्षिका एका वर्गासाठी सूचना post करते". यातली प्रत्येक गरज पुढे एक API call (धडा 03) आणि data ला विचारायचा एक प्रश्न (धडा 04) बनते.
Non-functional गरजा — ते काम किती चांगले होते, नेहमी एका आकड्यासह:
- latency — "read p99 < 200 ms" (100 पैकी 99 reads 200 ms पेक्षा कमी वेळात पूर्ण होतात),
- availability — "99.9% available" (30 दिवसांत सुमारे 43 मिनिटांचे अपयश, धडा 15),
- scale — "5 million पालक, reads ची संख्या posts पेक्षा ~100 : 1 ने जास्त",
- durability — "'posted' दाखवल्यानंतर सूचना कधीही हरवता कामा नये",
- शिवाय: consistency (धडा 10), security (धडा 14), cost (धडा 16). "जलद", "scalable" आणि "secure" या गरजा नाहीत. "p99 < 200 ms" ही गरज आहे.
मर्यादा (constraints) — तुम्ही बदलू शकत नाही अशा गोष्टी: team चा आकार, cloud, भाषा, budget, deadline, कायदे (उदाहरणार्थ, मुलांचा data कुठे साठवता येतो).
कक्षेबाहेर (out of scope) — तुम्ही आत्ता काय बनवणार नाही. ते मोठ्याने सांगितल्याने रचना अमर्याद वाढत नाही.
स्पष्टीकरणाचे प्रश्न — रचना बदलणारे प्रश्न: किती शाळा? peak कधी असतो? data किती काळ ठेवायचा? post कोण करू शकते?

🤔 का

कारण पुढचा प्रत्येक निर्णय या कागदावर अवलंबून असतो. प्रत्येक post मागे 100 reads म्हणजे "reads cache करा" (धडा 05). "कधीही हरवू नये" म्हणजे "posted" दाखवण्याआधी database मध्ये टिकाऊ write, आणि events साठी outbox (धडा 08). 4 जणांची team म्हणजे बारा services नाही, तर एक modular monolith (धडा 09). महिन्याला काही हजार dollars म्हणजे 200 servers लागणारी रचना बाद. कागदावरची एक ओळ बदला आणि योग्य रचना बदलते. म्हणूनच कागद आधी येतो.

🎤 मुलाखतीत vs 🏢 प्रत्यक्ष कामात

	🎤 design मुलाखत (45 मिनिटे)	🏢 प्रत्यक्ष काम (आठवडे)
प्रश्नांची उत्तरे कोण देते	मुलाखत घेणारे, एका वाक्यात	product owners, शिक्षिका, पालक, वकील, finance
तुम्ही किती वेळ घालवता	5 मिनिटे — मग पुढे जा	दिवस — आणि कागद नंतर बदलतो
आकडे	गोल आणि मिळून ठरवलेले ("समजा 5M users")	logs, सर्वेक्षणे, तशाच app मधून मोजलेले
ते काय तपासतात	तुम्ही काढण्याआधी विचारता का, आणि trade-offs सांगता का	launch वेळी — आणि नंतरही — system कागदावरच्या गरजा पूर्ण करते का
फलित	whiteboard वरची आकृती	लिहिलेले design doc + ADRs (धडा 16), इतरांनी तपासलेले

दोन्हीकडे सवय एकच: विचारा, लिहून ठेवा, मग काढा.

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

design/demo.py मधील requirements() सूचना फलकाचा कागद छापते: तीन functional ओळी, आकड्यांसह चार non-functional ओळी, तीन मर्यादा, कक्षेबाहेरची यादी आणि विचारायचे प्रश्न. मग धडा 02 या कागदावरचे आकडे design/blocks.py मधील estimate() ला देतो. खालच्या snippet मध्ये तुम्ही दोन स्पष्टीकरणाच्या प्रश्नांची उत्तरे वेगवेगळी देता — प्रत्येक सूचनेला किती reads? आणि सूचना किती काळ ठेवायच्या? — आणि system चा आकार कसा बदलतो ते पाहता.

🧪 करून पाहा

python3 design/demo.py requirements
python3 - <<'EOF'
import sys; sys.path.insert(0, "design"); from blocks import estimate
for ratio in (10, 100, 1000):
    e = estimate(5_000_000, 0.2, ratio, 2_000)
    print(f"reads per notice {ratio:>4} → peak {e['peak_rps']:>6,} req/s · {e['servers']:>3} servers")
for years in (1, 5, 10):
    print(f"notices kept {years:>2} y → {estimate(5_000_000, 0.2, 100, 2_000, years=years)['storage_tb']:>5} TB")
EOF

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

requirements छापते:

── the brief: 'build a notice board app for 5 million parents'. Before drawing a box, write the sheet:
   functional     a teacher posts a notice to a class
                  a parent reads the notices of their children's classes
                  a parent gets a notification for urgent notices
   non-functional read p99 < 200 ms · post p99 < 500 ms
                  99.9% available
                  reads outnumber posts ~100 : 1
                  a notice must never be lost once 'posted' is shown
   constraints    team of 4 · AWS · Marathi + English
                  budget: a few thousand dollars a month
                  launch in 3 months
   out of scope (say it!): chat, payments, video · questions to ask: how many schools? peak time? data kept how long?

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

reads per notice   10 → peak    382 req/s ·   2 servers
reads per notice  100 → peak  3,507 req/s ·  12 servers
reads per notice 1000 → peak 34,757 req/s · 116 servers
notices kept  1 y →  2.19 TB
notices kept  5 y → 10.95 TB
notices kept 10 y →  21.9 TB

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

एका स्पष्टीकरणाच्या प्रश्नाचे एक उत्तर रचनेला 2 servers वरून 116 वर नेते. दुसरे उत्तर storage दुप्पट करते. तेच काम, तीच app ची कल्पना — पण वेगळी इमारत. म्हणूनच नियोजन कार्यालय काढण्याआधी विचारते: चित्र नव्हे, कागद आकार ठरवतो.

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

पहिल्याच मिनिटात boxes काढणे — reads, peak किंवा budget कोणालाही माहीत होण्याआधी
आकडे नसलेल्या non-functional गरजा: "ते जलद आणि scalable असायला हवे"
durability विसरणे: "आपण कधी सूचना गमावू शकतो का?" हा प्रश्न write path बदलतो (धडा 08)
कक्षेबाहेरची यादीच नाही — मग chat, payments आणि video एकेक करून आत घुसतात
काम 5 million चे असताना 1 billion users साठी रचना करणे (आणि team 4 जणांची असताना)
प्रश्न विचारणे पण उत्तरे सगळ्यांना दिसतील अशी लिहून न ठेवणे

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

प्रत्यक्ष कामात हा कागद design document चे पहिले पान असतो, कोणीही बांधायला सुरुवात करण्याआधी तपासलेले. नियोजन कार्यालय repo मध्ये ठेवते ती छोटी आवृत्ती:

# Notice board — requirements (v1, 2026-09)
## Functional
- F1 a teacher posts a notice to a class (text, optional photo, urgent flag)
- F2 a parent reads the notices of their children's classes, newest first
- F3 a parent gets a push/SMS for urgent notices
## Non-functional
- read p99 < 200 ms, post p99 < 500 ms (measured at the load balancer)
- 99.9% monthly availability; RPO 0 for posted notices, RTO 1 hour
- 5M parents, ~1M notices/day, ~100 reads per notice, peak ×3 at 7–9 am
## Constraints
- team of 4 · AWS ap-south-1 (children's data stays in India) · Marathi + English
- budget ~$3,000/month · launch in 3 months
## Out of scope (v1)
- chat, payments, video
## Open questions
- how many schools in year 1? · how long are notices kept? · may parents reply?

On a real account — काही मर्यादा पक्क्या असतात, ज्या रचना करण्याआधी तुम्ही पाहू शकता. उदाहरणार्थ, तुमच्या account मधील Amazon SNS ची SMS खर्च मर्यादा (5M तातडीचे SMS लहान default मर्यादा मोडतील):

aws sns get-sms-attributes --attributes MonthlySpendLimit
aws service-quotas list-service-quotas --service-code sns --query 'Quotas[].{name:QuotaName,value:Value}'

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: बहुतेक अपयशी projects एखाद्या कठीण algorithm मुळे अपयशी झाले नाहीत. त्यांनी चुकीची गोष्ट बांधली, किंवा बरोबर गोष्ट चुकीच्या आकड्यांसाठी बांधली. System मागणाऱ्या लोकांनी मान्यता दिलेला एका पानाचा कागद हा सर्वात स्वस्त उपाय आहे.

⏭️ पुढे

कागद म्हणतो "5 million पालक" आणि "प्रत्येक सूचनेला 100 reads". म्हणजे सेकंदाला किती requests? किती terabytes? किती servers? नियोजन कार्यालय आकडेमोड करते.

git checkout lesson-02-capacity

📋 Lesson 01 — Requirements & constraints: the planning office asks before it draws

📍 You are here: Lesson 01 of 18 · Next: lesson-02-capacity

📦 What's in this branch

The one habit this whole course is built on: before you draw a single box, write down what the system must do, how well, and within which limits. The brief is one line — "build a notice board app for 5 million parents" — and in this lesson it becomes a sheet with four parts: functional needs, non-functional needs with numbers, constraints and out of scope, plus the questions you ask the person who gave you the brief. Real files you will use all the way through:

design/blocks.py — the planning office's toolbox: estimates, a hash ring, an LRU cache, two rate limiters, quorums, 2PC and sagas, an outbox, fan-out (144 lines, zero dependencies)
design/designs.py — the worksheets: pagination cost, store choice, call chains, STRIDE, error budgets, a first bill, ADRs and six worked designs (107 lines)
design/demo.py — every lesson as a small program (python3 design/demo.py <section>; sections: requirements capacity api data cache balance queues events services consistency transactions ratelimit resilience security observability cost designs1 designs2)
design/test_design.py — 18 checks on the office's rules
demo-output.txt — what a healthy run prints

🎒 Before you start: you need Python 3 and nothing else — no cloud account, no pip install. The files hold teaching models with round example numbers (500 requests a second per server, 2 KB per notice, a peak of 3×). The method matters more than the digits. Commands marked on a real account need the AWS CLI (or Terraform, psql, …) and credentials, and they can cost money.

🧒 Explain like I'm 5

The school wants a new building. The head teacher, Katrina, walks into the planning office and says: "We need a new hall."

Dipika runs the planning office. She does not pick up a pencil and start drawing. She picks up a form 📋 and asks:

What happens in the hall? Assemblies? Exams? Sports? (what it must do)
How many children, and how fast must they get in? 600 children in 5 minutes? (how well)
What do we have? How much money, how much land, which builders, by when? (limits)
What will it NOT be? Not a swimming pool. Not a canteen. (out of scope)

A hall for 60 children and a hall for 6,000 are different buildings. If Dipika draws first and asks later, she draws the wrong building — and nobody notices until the walls are up.

Our "hall" is an app: a notice board where teachers post notices and 5 million parents read them. The planning office fills in the form first.

🗺️ Diagram

flowchart LR
    brief["📝 the brief<br/>'a notice board app<br/>for 5 million parents'"]
    q["❓ clarifying questions<br/>how many schools? peak time?<br/>data kept how long?"]
    subgraph sheet["📋 the requirements sheet"]
      f["✅ functional<br/>post · read · notify"]
      nf["📏 non-functional<br/>p99 < 200 ms · 99.9%<br/>100 reads : 1 post · never lost"]
      c["🧱 constraints<br/>team of 4 · AWS · Marathi + English<br/>few thousand $/month · 3 months"]
      o["🚫 out of scope<br/>chat · payments · video"]
    end
    next["🧮 lesson 02<br/>turn it into numbers"]
    brief --> q --> sheet --> next

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

❓ What

System design — deciding the parts of a system (the boxes), how they talk (the arrows), where the data lives and why, before most of the code is written. The output is a diagram plus the reasons.
Functional requirements — what the system does, written as actions a person can take: "a teacher posts a notice to a class". Each one later becomes an API call (lesson 03) and a question for the data (lesson 04).
Non-functional requirements — how well it does it, always with a number:
- latency — "read p99 < 200 ms" (99 of 100 reads finish in under 200 ms),
- availability — "99.9% available" (about 43 minutes of failure in 30 days, lesson 15),
- scale — "5 million parents, reads outnumber posts ~100 : 1",
- durability — "a notice must never be lost once 'posted' is shown",
- also: consistency (lesson 10), security (lesson 14), cost (lesson 16). "Fast", "scalable" and "secure" are not requirements. "p99 < 200 ms" is.
Constraints — facts you cannot change: team size, cloud, languages, budget, deadline, laws (for example, where children's data may be stored).
Out of scope — what you will not build now. Saying it out loud stops the design from growing without end.
Clarifying questions — the questions that change the design: how many schools? When is the peak? How long do we keep data? Who may post?

🤔 Why

Because every later decision depends on this sheet. 100 reads for every post means "cache the reads" (lesson 05). "Never lost" means a durable database write before "posted" is shown, and an outbox for the events (lesson 08). A team of 4 means one modular monolith, not twelve services (lesson 09). A few thousand dollars a month rules out a design that needs 200 servers. Change one line on the sheet and the right design changes. That is why the sheet comes first.

🎤 In an interview vs 🏢 in real work

	🎤 A design interview (45 minutes)	🏢 Real work (weeks)
Who answers the questions	the interviewer, in one sentence	product owners, teachers, parents, lawyers, finance
How long you spend	5 minutes — then move on	days — and the sheet changes later
Numbers	round and invented together ("say 5M users")	measured from logs, surveys, a similar app
What they judge	that you ask before you draw, and name trade-offs	that the system meets the sheet at launch — and after
Output	a whiteboard diagram	a written design doc + ADRs (lesson 16), reviewed by others

The habit is the same in both: ask, write it down, then draw.

🔧 How (in this repo)

requirements() in design/demo.py prints the notice board's sheet: three functional lines, four non-functional lines with numbers, three constraints, the out-of-scope list and the questions to ask. Lesson 02 then feeds the numbers on this sheet into estimate() in design/blocks.py. In the snippet below you answer two clarifying questions differently — how many reads per notice? and how long do we keep notices? — and watch the size of the system change.

🧪 Try it

python3 design/demo.py requirements
python3 - <<'EOF'
import sys; sys.path.insert(0, "design"); from blocks import estimate
for ratio in (10, 100, 1000):
    e = estimate(5_000_000, 0.2, ratio, 2_000)
    print(f"reads per notice {ratio:>4} → peak {e['peak_rps']:>6,} req/s · {e['servers']:>3} servers")
for years in (1, 5, 10):
    print(f"notices kept {years:>2} y → {estimate(5_000_000, 0.2, 100, 2_000, years=years)['storage_tb']:>5} TB")
EOF

✅ Verify — what you should see

requirements prints:

── the brief: 'build a notice board app for 5 million parents'. Before drawing a box, write the sheet:
   functional     a teacher posts a notice to a class
                  a parent reads the notices of their children's classes
                  a parent gets a notification for urgent notices
   non-functional read p99 < 200 ms · post p99 < 500 ms
                  99.9% available
                  reads outnumber posts ~100 : 1
                  a notice must never be lost once 'posted' is shown
   constraints    team of 4 · AWS · Marathi + English
                  budget: a few thousand dollars a month
                  launch in 3 months
   out of scope (say it!): chat, payments, video · questions to ask: how many schools? peak time? data kept how long?

Your snippet prints:

reads per notice   10 → peak    382 req/s ·   2 servers
reads per notice  100 → peak  3,507 req/s ·  12 servers
reads per notice 1000 → peak 34,757 req/s · 116 servers
notices kept  1 y →  2.19 TB
notices kept  5 y → 10.95 TB
notices kept 10 y →  21.9 TB

🏁 What you just proved

One answer to one clarifying question moves the design from 2 servers to 116. Another doubles the storage. Same brief, same app idea — a different building. That is why the planning office asks before it draws: the sheet, not the drawing, decides the shape.

⚠️ Common mistakes

drawing boxes in the first minute — before anyone knows the reads, the peak or the budget
non-functional needs with no numbers: "it must be fast and scalable"
forgetting durability: "can we ever lose a notice?" changes the write path (lesson 08)
no out-of-scope list — then chat, payments and video creep in one by one
designing for 1 billion users when the brief says 5 million (and the team is 4 people)
asking questions but not writing the answers down where everyone can see them

🏭 In production

In real work the sheet is the first page of a design document, reviewed before anyone builds. A short version the planning office keeps in the repo:

# Notice board — requirements (v1, 2026-09)
## Functional
- F1 a teacher posts a notice to a class (text, optional photo, urgent flag)
- F2 a parent reads the notices of their children's classes, newest first
- F3 a parent gets a push/SMS for urgent notices
## Non-functional
- read p99 < 200 ms, post p99 < 500 ms (measured at the load balancer)
- 99.9% monthly availability; RPO 0 for posted notices, RTO 1 hour
- 5M parents, ~1M notices/day, ~100 reads per notice, peak ×3 at 7–9 am
## Constraints
- team of 4 · AWS ap-south-1 (children's data stays in India) · Marathi + English
- budget ~$3,000/month · launch in 3 months
## Out of scope (v1)
- chat, payments, video
## Open questions
- how many schools in year 1? · how long are notices kept? · may parents reply?

On a real account — some constraints are hard limits you can look up before you design. For example, the SMS spending limit for Amazon SNS in your account (5M urgent SMS would break a small default limit):

aws sns get-sms-attributes --attributes MonthlySpendLimit
aws service-quotas list-service-quotas --service-code sns --query 'Quotas[].{name:QuotaName,value:Value}'

🏭 Why this matters in production: most failed projects did not fail on a hard algorithm. They built the wrong thing, or the right thing for the wrong numbers. A one-page sheet, signed off by the people who asked for the system, is the cheapest fix there is.

⏭️ Next

The sheet says "5 million parents" and "100 reads per notice". How many requests a second is that? How many terabytes? How many servers? The planning office does the numbers.

git checkout lesson-02-capacity

← Course homeall lessons Next →capacity

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