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

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

🧮 धडा 02 — Capacity अंदाज: रचनेचा आकार ठरवणारे आकडे

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

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

धडा 01, आणि पद्धतीची दुसरी पायरी: कागदाला ढोबळ आकड्यांत बदला — जे तुम्ही पाच मिनिटांत कागदावर काढू शकता — requests per second, peak, वर्षानुवर्षांचे storage (प्रतींसह), bandwidth आणि servers. design/blocks.py मधील estimate() गणित करते; design/demo.py मधील capacity() ते सूचना फलकासाठी चालवते.

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

कतरिना म्हणते नवा हॉल "खूप मुलांसाठी" आहे. दीपिका कार्यालयातील आकड्यांची जाणकार ऐश्वर्याला "खूप" चे आकडे करायला सांगते.

ऐश्वर्याला अचूक असण्याची गरज नाही. हॉल वर्गखोली, व्यायामशाळा की स्टेडियम एवढ्या आकाराचा आहे, एवढेच तिला कळायला हवे. म्हणून ती ढोबळ मोजते:

5 million पालक. शिक्षिका दर 5 पालकांमागे दिवसाला सुमारे 1 सूचना post करतात — म्हणजे सगळ्या शाळांत मिळून दिवसाला सुमारे 1 million सूचना.
प्रत्येक सूचना सुमारे 100 वेळा वाचली जाते. म्हणजे मोठे काम reads चे आहे, writes चे नाही.
एका दिवसात सुमारे 86,400 सेकंद असतात — त्याला 100,000 म्हणा. म्हणजे दिवसाला 1 million म्हणजे सेकंदाला सुमारे 12. सोपे.
सकाळी 8 वाजता सगळे एकदम app उघडतात: नेहमीच्या संख्येच्या 3 पट.
प्रत्येक सूचना 5 वर्षे ठेवली जाते, आणि एखादी जळली तर म्हणून कार्यालय नोंदवहीच्या 3 प्रती ठेवते.

आता ऐश्वर्या सांगू शकते: "ही व्यायामशाळा आहे, स्टेडियम नाही. वाचणारे खूप, लिहिणारे फार थोडे, आणि नोंदवही एका कपाटात मावते." ते वाक्य म्हणजे उत्तर. नेमके अंक नव्हेत.

🗺️ आकृती

flowchart LR
    u["👪 5M parents<br/>1M notices/day"] --> w["✍️ writes<br/>1M ÷ 86,400 ≈ 11.6/s"]
    w --> r["👀 reads ×100<br/>≈ 1,157/s"]
    r --> avg["📊 average<br/>≈ 1,169 req/s"]
    avg --> pk["⛰️ peak ×3<br/>≈ 3,507 req/s"]
    pk --> sv["🖥️ servers<br/>3,507 ÷ (500 × 60%) → 12"]
    w --> st["💾 storage<br/>1M × 2 KB × 365 × 5 × 3 copies<br/>≈ 10.95 TB"]
    pk --> bw["📶 bandwidth<br/>3,507 × 2 KB ≈ 7 MB/s"]
    sv --> shape["🧭 the SHAPE<br/>tiny writes · heavy reads<br/>→ cache the reads"]
    st --> shape

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

❓ काय

Back-of-the-envelope अंदाज — ढोबळ आकडे, जोरात गोल केलेले, मिनिटांत केलेले. उद्देश आहे परिमाणाचा क्रम (order of magnitude): सेकंदाला दहा, हजार की million?
तोंडपाठ असायला हव्यात अशा दहाच्या घाती:
- 1 हजार = 10^3 (KB), 1 million = 10^6 (MB), 1 billion = 10^9 (GB), 1 trillion = 10^12 (TB)
- एक दिवस ≈ 86,400 s ≈ 10^5 s → दिवसाला 1 million ≈ सेकंदाला 12
- एक महिना ≈ 2.6 million सेकंद; एक वर्ष ≈ 31.5 million सेकंद
- 2 KB × 1 million = 2 GB
Read/write ratio — प्रत्येक write मागे किती reads. सूचना फलकाचे 100 : 1 आहे: एक read-heavy system. Read-heavy म्हणते "cache करा आणि प्रती ठेवा". Write-heavy म्हणते "queue करा, batch करा आणि data विभागा".
Peak factor — सर्वात गर्दीचे मिनिट भागिले सरासरी. सकाळच्या सूचना, निकालाचा दिवस, सणाच्या शुभेच्छा: इथे ×3. रचना peak साठी करा, सरासरीसाठी नाही.
Storage = दिवसाचे writes × प्रत्येकाचे bytes × 365 × वर्षे × प्रती (replicas). या प्रती म्हणजे खऱ्या disks, ज्यांचे तुम्ही पैसे देता.
Bandwidth (egress) — तुमच्या servers मधून सेकंदाला बाहेर जाणारे bytes. estimate() peak वेळी प्रत्येक request मागे एक 2 KB ची सूचना मोजते — पहिला अंदाज. 20 सूचनांचे feed page जास्त data हलवते; photos सुद्धा.
Servers = peak ÷ (एक server जे करतो × 60%). 60% मुळे अचानक वाढीसाठी किंवा एखादा server गेल्यास headroom राहते. प्रत्येक server ला 500 req/s हा उदाहरणाचा आकडा आहे — खरा आकडा load test देतो (Scaling शाळा, धडा 02).

🤔 का

कारण आकडे आकार ठरवतात. सेकंदाला 11.6 writes खूपच कमी आहेत: एक database primary ते सहज हाताळतो, म्हणून तुम्हाला sharding लागत नाही. Peak वेळी सेकंदाला 3,507 reads हे खरे काम आहे, आणि त्यातले 99% reads आहेत, म्हणून तुम्हाला cache हवाच (धडा 05). 5 वर्षांत 11 TB एका database cluster मध्ये मावतो. आकड्यांशिवाय लोक अंदाज बांधतात — आणि अंदाज दोन्ही दिशांनी चुकू शकतात: पहिल्याच दिवशी कोसळणारी रचना, किंवा एक server सहज उचलेल अशा load साठी 40 microservices आणि sharded database.

उत्तर म्हणजे आकार, अंक नव्हे. तुम्ही 12 servers म्हणालात की 14, हे कोणी तपासणार नाही. तुम्ही "writes लहान, reads जड" हे पाहिले का आणि reads च्या पुढे cache ठेवला का, हे ते तपासतील.

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

design/blocks.py मधील estimate(daily_users, actions_per_user, read_write_ratio, bytes_per_write, peak_factor=3, per_server_rps=500, years=5, replicas=3):

दिवसाचे writes = users × प्रत्येकाच्या कृती (5M × 0.2 = 1M सूचना)
दिवसाचे reads = writes × ratio (× 100)
सरासरी req/s = (reads + writes) ÷ DAY (86,400)
peak = सरासरी × peak factor
servers = ceil(peak ÷ (per_server_rps × 0.6))
storage = दिवसाचे writes × bytes × 365 × वर्षे × replicas
egress = peak × प्रत्येकाचे bytes

human() bytes ना KB, MB, GB, TB मध्ये छापते.

🧪 करून पाहा

python3 design/demo.py capacity
python3 - <<'EOF'
import sys; sys.path.insert(0, "design"); from blocks import estimate, human, DAY
print(f"1M a day = {1_000_000 / DAY:.1f} per second · 100M a day = {100_000_000 / DAY:,.0f} per second")
for users in (500_000, 5_000_000, 50_000_000):
    e = estimate(users, 0.2, 100, 2_000)
    print(f"{users:>10,} parents → peak {e['peak_rps']:>6,} req/s · {e['servers']:>3} servers · {e['storage_tb']:>6} TB")
for peak in (2, 3, 10):
    print(f"peak ×{peak:<2} → {estimate(5_000_000, 0.2, 100, 2_000, peak_factor=peak)['servers']:>2} servers")
for copies in (1, 3):
    print(f"replicas={copies} → {estimate(5_000_000, 0.2, 100, 2_000, replicas=copies)['storage_tb']:>5} TB in 5 years")
print("one year of notices, one copy:", human(1_000_000 * 2_000 * 365))
EOF

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

capacity छापते:

── 5M parents · 1M notices a day across all schools · 100 reads per notice · 2 KB each · peak ×3 · 5 years · 3 copies
   writes_per_s   11.6
   reads_per_s    1157.4
   avg_rps        1169
   peak_rps       3507
   servers        12
   storage_tb     10.95
   egress_mb_s    7.0
   rules of thumb: a day ≈ 86,400 s ≈ 10^5 · 1M/day ≈ 12/s · 2 KB × 1M = 2.0 GB
   the answer is a SHAPE, not a digit: tiny writes, heavy reads, ~11 TB in 5 years → cache the reads; one database cluster is enough

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

1M a day = 11.6 per second · 100M a day = 1,157 per second
   500,000 parents → peak    351 req/s ·   2 servers ·   1.09 TB
 5,000,000 parents → peak  3,507 req/s ·  12 servers ·  10.95 TB
50,000,000 parents → peak 35,069 req/s · 117 servers ·  109.5 TB
peak ×2  →  8 servers
peak ×3  → 12 servers
peak ×10 → 39 servers
replicas=1 →  3.65 TB in 5 years
replicas=3 → 10.95 TB in 5 years
one year of notices, one copy: 730.0 GB

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

दहापट पालक म्हणजे सगळेच दहापट — गणित सोपे आहे, आणि तोच मुद्दा आहे. 50 million पालकांवर, 109.5 TB आणि 117 servers हा वेगळा आकार आहे: आता data विभागावा लागू शकतो (Database शाळा) आणि reads cache करावेच लागतात. ×10 चा peak (निकालाचा दिवस) 12 नव्हे तर 39 servers मागतो. आणि 3 प्रती disk तिप्पट करतात: 3.65 TB चे 10.95 TB होतात.

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

सरासरीसाठी रचना करणे आणि peak विसरणे (सकाळी 8 ची गर्दी ×3; निकालाच्या दिवशी त्याहून जास्त)
प्रती विसरणे: replicas, backups आणि indexes सगळे disk घेतात
आकार नसलेले नेमके अंक: "आपल्याला 11.69 servers लागतील" आणि निष्कर्ष काहीच नाही
गणितात servers 100% वर चालवणे — मग एक server गेला की बाकीच्यांवर जास्त भार येतो
bits आणि bytes ची गल्लत: 1 Gb/s (gigabits) म्हणजे फक्त 125 MB/s (megabytes)
उदाहरणाच्या "प्रत्येक server ला 500 req/s" वर विश्वास ठेवणे — स्वतःच्या service चा load test करा

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

प्रत्यक्ष कामात आकडे फक्त अंदाजांतून नाही, तर मोजमापांतून येतात. On a real account — खरा peak factor load balancer च्या request count मध्ये, मिनिटा-मिनिटाला असतो; सर्वात गर्दीचे मिनिट दिवसाच्या सरासरीने भागा:

aws cloudwatch get-metric-statistics --namespace AWS/ApplicationELB \
    --metric-name RequestCount --statistics Sum --period 60 \
    --dimensions Name=LoadBalancer,Value=app/notice-alb/50dc6c495c0c9188 \
    --start-time 2026-09-21T00:00:00Z --end-time 2026-09-22T00:00:00Z

आणि प्रत्येक row चे खरे bytes database मध्ये असतात — खऱ्या data असलेल्या प्रतीवर ते मोजा:

-- PostgreSQL: average stored size of one notice row, and the table + index size
SELECT avg(pg_column_size(n.*)) AS bytes_per_row FROM notices n;
SELECT pg_size_pretty(pg_total_relation_size('notices'));

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: अंदाज design doc मध्ये त्याच्या गृहितकांसह ठेवा ("प्रत्येक सूचनेला 100 reads, peak ×3"). खरा traffic आला की तुलना करा. आठवडा 2 मध्ये सापडलेले चुकीचे गृहितक स्वस्त असते; निकालाच्या दिवशी सापडले, तर ते outage असते.

⏭️ पुढे

आता आकार कळला. कोणीही code लिहिण्याआधी, नियोजन कार्यालय करार (contract) लिहिते: app कोणते requests पाठवतो आणि server काय उत्तर देतो.

git checkout lesson-03-api-design

🧮 Lesson 02 — Capacity estimation: the numbers that decide the shape

📍 You are here: Lesson 02 of 18 · Previous: lesson-01-requirements · Next: lesson-03-api-design

📦 What's in this branch

Lesson 01, plus the second step of the method: turn the sheet into rough numbers you can work out on paper in five minutes — requests per second, the peak, storage over the years (with copies), bandwidth and servers. estimate() in design/blocks.py does the arithmetic; capacity() in design/demo.py runs it for the notice board.

🧒 Explain like I'm 5

Katrina says the new hall is for "a lot of children". Dipika asks Aishwarya, the office's number person, to make "a lot" into numbers.

Aishwarya does not need to be exact. She needs to know if the hall is the size of a classroom, a gym or a stadium. So she counts roughly:

5 million parents. Teachers post about 1 notice a day for every 5 parents — so about 1 million notices a day across all schools.
Each notice is read about 100 times. So reads are the big job, not writes.
A day has about 86,400 seconds — call it 100,000. So 1 million a day is about 12 a second. Easy.
At 8 in the morning, everybody opens the app at once: 3 times the normal number.
Every notice is kept for 5 years, and the office keeps 3 copies of the register in case one burns.

Now Aishwarya can say: "It is a gym, not a stadium. Lots of readers, very few writers, and the register fits in one cupboard." That sentence is the answer. The exact digits are not.

🗺️ Diagram

flowchart LR
    u["👪 5M parents<br/>1M notices/day"] --> w["✍️ writes<br/>1M ÷ 86,400 ≈ 11.6/s"]
    w --> r["👀 reads ×100<br/>≈ 1,157/s"]
    r --> avg["📊 average<br/>≈ 1,169 req/s"]
    avg --> pk["⛰️ peak ×3<br/>≈ 3,507 req/s"]
    pk --> sv["🖥️ servers<br/>3,507 ÷ (500 × 60%) → 12"]
    w --> st["💾 storage<br/>1M × 2 KB × 365 × 5 × 3 copies<br/>≈ 10.95 TB"]
    pk --> bw["📶 bandwidth<br/>3,507 × 2 KB ≈ 7 MB/s"]
    sv --> shape["🧭 the SHAPE<br/>tiny writes · heavy reads<br/>→ cache the reads"]
    st --> shape

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

❓ What

Back-of-the-envelope estimate — rough numbers, rounded hard, done in minutes. The goal is the order of magnitude: tens, thousands or millions per second?
Powers of ten you should know by heart:
- 1 thousand = 10^3 (KB), 1 million = 10^6 (MB), 1 billion = 10^9 (GB), 1 trillion = 10^12 (TB)
- a day ≈ 86,400 s ≈ 10^5 s → 1 million a day ≈ 12 a second
- a month ≈ 2.6 million seconds; a year ≈ 31.5 million seconds
- 2 KB × 1 million = 2 GB
Read/write ratio — how many reads for each write. The notice board is 100 : 1: a read-heavy system. Read-heavy says "cache and copy". Write-heavy says "queue, batch and split the data".
Peak factor — the busiest minute divided by the average. Morning notices, results day, a festival greeting: here ×3. Design for the peak, not the average.
Storage = writes per day × bytes each × 365 × years × copies (replicas). The copies are real disks you pay for.
Bandwidth (egress) — bytes a second leaving your servers. estimate() counts one 2 KB notice per request at the peak — a first guess. A feed page with 20 notices moves more; so photos would.
Servers = peak ÷ (what one server does × 60%). The 60% leaves headroom for a sudden rise or a lost server. 500 req/s per server is an example number — a load test gives you the real one (the Scaling school, lesson 02).

🤔 Why

Because the numbers decide the shape. 11.6 writes a second is tiny: one database primary handles it easily, so you do not need sharding. 3,507 reads a second at the peak is real work, and 99% of it is reads, so you do want a cache (lesson 05). 11 TB in 5 years fits in one database cluster. Without the numbers people guess — and guesses can be wrong in both directions: a design that fails on day one, or 40 microservices and a sharded database for a load one server could carry.

The answer is a shape, not a digit. Nobody will check that you said 12 servers and not 14. They will check that you saw "tiny writes, heavy reads" and put a cache in front of the reads.

🔧 How (in this repo)

estimate(daily_users, actions_per_user, read_write_ratio, bytes_per_write, peak_factor=3, per_server_rps=500, years=5, replicas=3) in design/blocks.py:

writes a day = users × actions each (5M × 0.2 = 1M notices)
reads a day = writes × ratio (× 100)
average req/s = (reads + writes) ÷ DAY (86,400)
peak = average × peak factor
servers = ceil(peak ÷ (per_server_rps × 0.6))
storage = writes a day × bytes × 365 × years × replicas
egress = peak × bytes each

human() prints bytes as KB, MB, GB, TB.

🧪 Try it

python3 design/demo.py capacity
python3 - <<'EOF'
import sys; sys.path.insert(0, "design"); from blocks import estimate, human, DAY
print(f"1M a day = {1_000_000 / DAY:.1f} per second · 100M a day = {100_000_000 / DAY:,.0f} per second")
for users in (500_000, 5_000_000, 50_000_000):
    e = estimate(users, 0.2, 100, 2_000)
    print(f"{users:>10,} parents → peak {e['peak_rps']:>6,} req/s · {e['servers']:>3} servers · {e['storage_tb']:>6} TB")
for peak in (2, 3, 10):
    print(f"peak ×{peak:<2} → {estimate(5_000_000, 0.2, 100, 2_000, peak_factor=peak)['servers']:>2} servers")
for copies in (1, 3):
    print(f"replicas={copies} → {estimate(5_000_000, 0.2, 100, 2_000, replicas=copies)['storage_tb']:>5} TB in 5 years")
print("one year of notices, one copy:", human(1_000_000 * 2_000 * 365))
EOF

✅ Verify — what you should see

capacity prints:

── 5M parents · 1M notices a day across all schools · 100 reads per notice · 2 KB each · peak ×3 · 5 years · 3 copies
   writes_per_s   11.6
   reads_per_s    1157.4
   avg_rps        1169
   peak_rps       3507
   servers        12
   storage_tb     10.95
   egress_mb_s    7.0
   rules of thumb: a day ≈ 86,400 s ≈ 10^5 · 1M/day ≈ 12/s · 2 KB × 1M = 2.0 GB
   the answer is a SHAPE, not a digit: tiny writes, heavy reads, ~11 TB in 5 years → cache the reads; one database cluster is enough

Your snippet prints:

1M a day = 11.6 per second · 100M a day = 1,157 per second
   500,000 parents → peak    351 req/s ·   2 servers ·   1.09 TB
 5,000,000 parents → peak  3,507 req/s ·  12 servers ·  10.95 TB
50,000,000 parents → peak 35,069 req/s · 117 servers ·  109.5 TB
peak ×2  →  8 servers
peak ×3  → 12 servers
peak ×10 → 39 servers
replicas=1 →  3.65 TB in 5 years
replicas=3 → 10.95 TB in 5 years
one year of notices, one copy: 730.0 GB

🏁 What you just proved

Ten times the parents gives ten times everything — the arithmetic is simple, and that is the point. At 50 million parents, 109.5 TB and 117 servers is a different shape: now the data may need splitting (the Database school) and the reads must be cached. A peak of ×10 (results day) needs 39 servers, not 12. And the 3 copies triple the disk: 3.65 TB becomes 10.95 TB.

⚠️ Common mistakes

designing for the average and forgetting the peak (the 8 am rush is ×3; results day is more)
forgetting the copies: replicas, backups and indexes all take disk
exact digits with no shape: "we need 11.69 servers" and no conclusion
running servers at 100% in the arithmetic — then one lost server overloads the rest
mixing bits and bytes: 1 Gb/s (gigabits) is only 125 MB/s (megabytes)
trusting the example "500 req/s per server" — load-test your own service

🏭 In production

In real work the numbers come from measurements, not only from guesses. On a real account — the real peak factor is in the load balancer's request count, minute by minute; divide the busiest minute by the daily average:

aws cloudwatch get-metric-statistics --namespace AWS/ApplicationELB \
    --metric-name RequestCount --statistics Sum --period 60 \
    --dimensions Name=LoadBalancer,Value=app/notice-alb/50dc6c495c0c9188 \
    --start-time 2026-09-21T00:00:00Z --end-time 2026-09-22T00:00:00Z

And the real bytes per row are in the database — measure them on a copy with real data:

-- PostgreSQL: average stored size of one notice row, and the table + index size
SELECT avg(pg_column_size(n.*)) AS bytes_per_row FROM notices n;
SELECT pg_size_pretty(pg_total_relation_size('notices'));

🏭 Why this matters in production: put the estimate in the design doc with its assumptions ("100 reads per notice, peak ×3"). When real traffic arrives, compare. A wrong assumption found in week 2 is cheap; found on results day, it is an outage.

⏭️ Next

Now we know the size. Before anyone writes code, the planning office writes the contract: which requests the app sends and what the server answers.

git checkout lesson-03-api-design

← Previousrequirements Next →api design

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