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

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

🎪 धडा 01 — Scaling का: शाळेच्या जत्रेतील निकालाचा दिवस

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

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

हा पूर्ण कोर्स सोडवतो ती एकच समस्या: सामान्य दिवशी शाळेच्या website ला सेकंदाला 40 भेटी मिळतात. निकालाच्या दिवशी त्या 2,000 होतात. Site सगळ्यांसाठी जलद राहिली पाहिजे — page (UI), त्यामागचा API, आणि त्यामागचा database. संपूर्ण कोर्सभर तुम्ही वापराल त्या खऱ्या files:

scale/sim.py — शाळेची जत्रा: web app कसा scale होतो याचे लहान, प्रामाणिक simulations, शुद्ध Python मध्ये (227 ओळी, शून्य dependencies)
scale/demo.py — प्रत्येक धडा एक लहान program म्हणून (python3 scale/demo.py <section>; sections: why measure cdn edge balance autoscale kubernetes serverless cache replicas shards queues resilience)
scale/test_scale.py — जत्रेच्या नियमांवर 13 checks
demo-output.txt — निरोगी run काय print करतो

🎒 सुरू करण्याआधी: तुम्हाला फक्त Python 3 हवे — AWS account नको, pip install नको. sim.py मध्ये गोल उदाहरणाच्या आकड्यांसह शिकवण्यासाठीचे models आहेत (एका server ला सेकंदाला 150 requests, 2 मिनिटांचा warm-up, 200 ms चा Lambda). खऱ्या systems मध्ये network jitter, retries आणि limits येतात — एखाद्या आकड्यावर विश्वास ठेवण्याआधी खऱ्या system चा load test करा (धडा 02). on a real account असे लिहिलेल्या commands साठी AWS CLI (किंवा Terraform / kubectl) आणि credentials लागतात, आणि त्यांचे पैसे लागू शकतात.

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

दरवर्षी निकालाच्या दिवशी शाळा जत्रा भरवते. सामान्य दिवशी काही पालक office मध्ये येतात. एका खिडकीवर एक कारकून पुरेसा असतो.

मग निकाल सूचना फलकावर लागतो. सगळे एकदम येतात. रांग फाटकाबाहेर जाऊन रस्त्यापर्यंत पोहोचते.

मुख्याध्यापिका दीपिकासमोर दोन पर्याय आहेत:

मोठी खिडकी 🪑➡️🛋️ — मोठ्या टेबलावर जास्त जलद कारकून बसवा. सोपे. पण सर्वात मोठे टेबल कधीतरी संपतेच, आणि तो एकच कारकून आजारी पडला तर कुणालाच सेवा मिळत नाही.
जास्त खिडक्या 🪑🪑🪑 — शेजारी शेजारी दहा खिडक्या उघडा, आणि फाटकावर एक मदतनीस ठेवा जो प्रत्येक पालकाला मोकळ्या खिडकीकडे पाठवतो. इथे सर्वात मोठा size नसतो. पण प्रत्येक खिडकी प्रत्येक पालकाला मदत करू शकली पाहिजे — कोणतीही खिडकी स्वतःची खाजगी वही ठेवू शकत नाही.

आणि आणखी एक नियम: जत्रा तिच्या सर्वात हळू भागाइतकीच जलद असते. सगळ्या दहा खिडक्यांना office च्या एकाच नोंदवहीची वाट पाहावी लागत असेल तर दहा खिडक्यांचा उपयोग होत नाही.

🗺️ आकृती

flowchart LR
    p["👪 parents<br/>40 → 2,000 per second"]
    subgraph up["🛋️ scale UP"]
      big["one bigger counter<br/>more CPU, more memory<br/>there is a biggest size"]
    end
    subgraph out["🪑🪑🪑 scale OUT"]
      lb["⚖️ helper at the gate<br/>load balancer"]
      c1["counter 1"]
      c2["counter 2"]
      c3["counter …23"]
      lb --> c1
      lb --> c2
      lb --> c3
    end
    db["📒 the one register<br/>database — the slowest part?"]
    p --> big
    p --> lb
    big --> db
    c1 --> db
    c2 --> db
    c3 --> db

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

❓ काय

Scaling — load वाढला तरी system जलद आणि बरोबर चालू ठेवणे.
Load — किती काम येते, सहसा requests per second (req/s) मध्ये मोजले जाते.
Scale up (vertical) — मोठे machine: जास्त CPU, जास्त memory. Code बदलायला नको. पण सर्वात मोठा size कधीतरी संपतोच, आणि size बदलणे म्हणजे सहसा restart.
Scale out (horizontal) — तेच काम करणारी जास्त machines, load balancer मागे. मर्यादा नाही, आणि एक machine गेले तरी ते अनेकांपैकी एकच असते. पण app ने ते होऊ दिले पाहिजे: user चा data फक्त एकाच server च्या आत ठेवायचा नाही (धडा 05).
Headroom — प्रत्येक server 100% नव्हे तर सुमारे 60% व्यस्त ठेवा, म्हणजे अचानक load वाढला किंवा एखादा server गेला तरी बाकीच्यांवर जास्त भार पडत नाही. servers_needed() 60% वापरते.
सर्वात हळू भाग वेग ठरवतो — web app चे तीन tiers असतात, आणि प्रत्येकाला स्वतःचा आराखडा हवा: UI (pages, scripts, चित्रे — धडे 03–04), API (धडे 05–08) आणि database (धडे 09–12). त्यानंतर धडा 13 एखादा भाग बिघडला तरी तिन्ही चालू ठेवतो.

🤔 का

कारण traffic सपाट नसते. निकालाचा दिवस, sale, एखादी बातमी किंवा TV जाहिरात एका मिनिटात सामान्य load च्या 50 पट load आणू शकते. 40 req/s ला ठीक चालणारी site 2,000 ला कोसळते — आधी हळू pages, मग errors, मग कधीच रिकामी न होणारी रांग. 50 पट मोठे एक machine तुम्ही विकत घेऊ शकत नाही. App ने परवानगी दिली तर तुम्ही 20 लहान machines आणखी जोडू शकता. हा कोर्स app ला ते शक्य करायला शिकवतो, एका tier मागून दुसरा.

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

scale/sim.py मधले servers_needed(rps, per_server_rps, target_util=0.6) load ला एक server 60% वर जितके करू शकतो त्याने भागते आणि वरच्या पूर्णांकात नेते: ceil(rps / (per_server_rps × 0.6)). scale/demo.py मधले why() त्याला एका server ला 150 req/s (उदाहरणाचा आकडा) धरून 40, 400 आणि 2,000 req/s साठी विचारते. तुमचा स्वतःचा आकडा load test मधून येतो (धडा 02).

🧪 करून पाहा

python3 scale/demo.py why
python3 - <<'EOF'
import sys; sys.path.insert(0, "scale"); from sim import servers_needed
for per in (150, 300, 600):
    print(f"per server {per:>3} req/s → {servers_needed(2000, per):>2} servers for 2,000 req/s")
for u in (0.6, 0.8, 1.0):
    print(f"run each server at {u:.0%} → {servers_needed(2000, 150, u):>2} servers")
print("results x10 (20,000 req/s) →", servers_needed(20000, 150), "servers")
EOF
python3 scale/test_scale.py

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

why हे print करते:

      40 req/s at 150 req/s per server (run at 60%) →   1 server(s)
     400 req/s at 150 req/s per server (run at 60%) →   5 server(s)
    2000 req/s at 150 req/s per server (run at 60%) →  23 server(s)

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

per server 150 req/s → 23 servers for 2,000 req/s
per server 300 req/s → 12 servers for 2,000 req/s
per server 600 req/s →  6 servers for 2,000 req/s
run each server at 60% → 23 servers
run each server at 80% → 17 servers
run each server at 100% → 14 servers
results x10 (20,000 req/s) → 223 servers

Tests शेवटी 13/13 passed दाखवतात.

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

मोठ्या server ला (300 किंवा 600 req/s) कमी प्रती लागतात — हे scaling up. त्याच server च्या जास्त प्रती — हे scaling out, आणि ते 10× ला सुद्धा चालत राहते (223 servers). 100% वर चालवल्याने हिशोबात 9 servers वाचतात, पण अचानक वाढीसाठी किंवा गेलेल्या server साठी जागाच उरत नाही.

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

प्रत्येक server ला थांबवून ठेवणारी ती एक हळू query दुरुस्त करण्याऐवजी सतत scale up करत राहणे
logins किंवा uploads एकाच server च्या आत ठेवणाऱ्या app ला scale out करणे (धडा 05 हे दुरुस्त करतो)
सर्वात गर्दीच्या मिनिटाऐवजी सरासरी दिवसासाठी नियोजन करणे
database हा सर्वात हळू भाग असताना API servers वाढवणे — आता जास्त servers त्याची वाट पाहतात
इथल्या उदाहरणाच्या आकड्यांवर विश्वास ठेवणे: एका server ला 150 req/s हा धड्यासाठीचा गोल आकडा आहे

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

On a real account — एका EC2 instance ला scale up करणे म्हणजे ते थांबवणे, type बदलणे आणि पुन्हा सुरू करणे (त्या machine कडून काही मिनिटे सेवा नाही):

aws ec2 stop-instances --instance-ids i-0123456789abcdef0
aws ec2 wait instance-stopped --instance-ids i-0123456789abcdef0
aws ec2 modify-instance-attribute --instance-id i-0123456789abcdef0 --instance-type '{"Value": "m7g.2xlarge"}'
aws ec2 start-instances --instance-ids i-0123456789abcdef0

Scaling out म्हणजे load balancer मागच्या Auto Scaling group वरचा एक आकडा (धडा 06):

aws autoscaling set-desired-capacity --auto-scaling-group-name school-api --desired-capacity 23

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: निकालाच्या दिवसाआधी प्रत्येक tier साठी एक ओळ लिहा: "UI … ने scale होतो, API … ने scale होतो, database … ने scale होतो". ज्या tier ला उत्तर नाही तोच आधी कोसळतो.

⏭️ पुढे

"सेकंदाला 2,000" आणि "एका server ला 150" हे आकडे आहेत. खरे आकडे कुठून येतात? बांधण्याआधी मोजा.

git checkout lesson-02-measuring-load

🎪 Lesson 01 — Why scaling: results day at the school fair

📍 You are here: Lesson 01 of 13 · Next: lesson-02-measuring-load

📦 What's in this branch

The one problem this whole course solves: on a normal day the school website gets 40 visits a second. On results day it gets 2,000. The site must stay fast for everyone — the page (the UI), the API behind it, and the database behind that. Real files you will use all the way through:

scale/sim.py — the school fair: small, honest simulations of how a web app scales, in pure Python (227 lines, zero dependencies)
scale/demo.py — every lesson as a small program (python3 scale/demo.py <section>; sections: why measure cdn edge balance autoscale kubernetes serverless cache replicas shards queues resilience)
scale/test_scale.py — 13 checks on the fair's rules
demo-output.txt — what a healthy run prints

🎒 Before you start: you need Python 3 and nothing else — no AWS account, no pip install. sim.py holds teaching models with round example numbers (150 requests a second per server, a 2-minute warm-up, a 200 ms Lambda). Real systems add network jitter, retries and limits — load-test the real thing (lesson 02) before you trust a number. Commands marked on a real account need the AWS CLI (or Terraform / kubectl) and credentials, and they can cost money.

🧒 Explain like I'm 5

Every year the school holds a fair on results day. On a normal day a few parents come to the office. One clerk at one counter is enough.

Then the results go up on the notice board. Everyone comes at once. The queue goes out of the gate and down the road.

The head teacher, Dipika, has two choices:

A bigger counter 🪑➡️🛋️ — put a faster clerk at a bigger desk. Simple. But there is always a biggest desk, and if that one clerk is ill, nobody is served.
More counters 🪑🪑🪑 — open ten counters side by side, with a helper at the gate who sends each parent to a free one. There is no biggest size. But every counter must be able to help every parent — no counter can keep a private notebook.

And one more rule: the fair is only as fast as its slowest part. Ten counters do not help if all of them must wait for the one office register.

🗺️ Diagram

flowchart LR
    p["👪 parents<br/>40 → 2,000 per second"]
    subgraph up["🛋️ scale UP"]
      big["one bigger counter<br/>more CPU, more memory<br/>there is a biggest size"]
    end
    subgraph out["🪑🪑🪑 scale OUT"]
      lb["⚖️ helper at the gate<br/>load balancer"]
      c1["counter 1"]
      c2["counter 2"]
      c3["counter …23"]
      lb --> c1
      lb --> c2
      lb --> c3
    end
    db["📒 the one register<br/>database — the slowest part?"]
    p --> big
    p --> lb
    big --> db
    c1 --> db
    c2 --> db
    c3 --> db

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

❓ What

Scaling — keeping a system fast and correct when the load grows.
Load — how much work arrives, usually counted as requests per second (req/s).
Scale up (vertical) — a bigger machine: more CPU, more memory. No code changes. But there is always a biggest size, and changing the size usually means a restart.
Scale out (horizontal) — more machines doing the same job, behind a load balancer. No ceiling, and one lost machine is only one of many. But the app must allow it: no user data kept only inside one server (lesson 05).
Headroom — run each server at about 60% busy, not 100%, so a sudden rise or a lost server does not overload the others. servers_needed() uses 60%.
The slowest part sets the pace — a web app has three tiers, and each needs its own plan: the UI (pages, scripts, pictures — lessons 03–04), the API (lessons 05–08) and the database (lessons 09–12). Lesson 13 then keeps all three open when one part breaks.

🤔 Why

Because traffic is not flat. Results day, a sale, a news story or a TV advert can bring 50 times the normal load in one minute. A site that is fine at 40 req/s fails at 2,000 — slow pages first, then errors, then a queue that never empties. You cannot buy one machine that is 50 times bigger. You can add 20 more small ones, if the app allows it. This course is about making the app allow it, tier by tier.

🔧 How (in this repo)

servers_needed(rps, per_server_rps, target_util=0.6) in scale/sim.py divides the load by what one server can do at 60% and rounds up: ceil(rps / (per_server_rps × 0.6)). why() in scale/demo.py asks it for 40, 400 and 2,000 req/s with 150 req/s per server — an example number. Your own number comes from a load test (lesson 02).

🧪 Try it

python3 scale/demo.py why
python3 - <<'EOF'
import sys; sys.path.insert(0, "scale"); from sim import servers_needed
for per in (150, 300, 600):
    print(f"per server {per:>3} req/s → {servers_needed(2000, per):>2} servers for 2,000 req/s")
for u in (0.6, 0.8, 1.0):
    print(f"run each server at {u:.0%} → {servers_needed(2000, 150, u):>2} servers")
print("results x10 (20,000 req/s) →", servers_needed(20000, 150), "servers")
EOF
python3 scale/test_scale.py

✅ Verify — what you should see

why prints:

      40 req/s at 150 req/s per server (run at 60%) →   1 server(s)
     400 req/s at 150 req/s per server (run at 60%) →   5 server(s)
    2000 req/s at 150 req/s per server (run at 60%) →  23 server(s)

Your snippet prints:

per server 150 req/s → 23 servers for 2,000 req/s
per server 300 req/s → 12 servers for 2,000 req/s
per server 600 req/s →  6 servers for 2,000 req/s
run each server at 60% → 23 servers
run each server at 80% → 17 servers
run each server at 100% → 14 servers
results x10 (20,000 req/s) → 223 servers

The tests end with 13/13 passed.

🏁 What you just proved

A bigger server (300 or 600 req/s) needs fewer copies — that is scaling up. More copies of the same server — that is scaling out, and it keeps working at 10× (223 servers). Running at 100% saves 9 servers in the arithmetic, but leaves no room for a spike or a lost server.

⚠️ Common mistakes

scaling up forever instead of fixing the one slow query that makes every server wait
scaling out an app that keeps logins or uploads inside one server (lesson 05 fixes this)
planning for the average day, not the busiest minute
adding API servers when the database is the slowest part — now more servers wait on it
trusting the example numbers here: 150 req/s per server is a round number for the lesson

🏭 In production

On a real account — scaling up one EC2 instance means stopping it, changing the type and starting it again (a few minutes with no service from that machine):

aws ec2 stop-instances --instance-ids i-0123456789abcdef0
aws ec2 wait instance-stopped --instance-ids i-0123456789abcdef0
aws ec2 modify-instance-attribute --instance-id i-0123456789abcdef0 --instance-type '{"Value": "m7g.2xlarge"}'
aws ec2 start-instances --instance-ids i-0123456789abcdef0

Scaling out is a number on an Auto Scaling group behind a load balancer (lesson 06):

aws autoscaling set-desired-capacity --auto-scaling-group-name school-api --desired-capacity 23

🏭 Why this matters in production: before results day, write down one line per tier: "the UI scales by …, the API scales by …, the database scales by …". A tier with no answer is the one that fails first.

⏭️ Next

"2,000 a second" and "150 per server" are numbers. Where do real numbers come from? Measure before you build.

git checkout lesson-02-measuring-load

← Course homeall lessons Next →measuring load

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