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

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

🚧 धडा 12 — Backpressure & संपूर्ण चित्र: "नंतर या" लवकर सांगा

📍 तुम्ही इथे आहात: 12 पैकी धडा 12 · मागे: lesson-11-exactly-once · शेवटचा धडा 🎓

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

धडे 01–11, आणि backpressure: node करू शकते त्यापेक्षा जास्त काम आले की unbounded रांग त्या overload चे रूपांतर सतत वाढत जाणाऱ्या थांबण्यात करते; bounded रांग "नंतर या" (429 / 503 + Retry-After) असे सांगून लवकर नकार देते आणि थांबणे कमी ठेवते. शिवाय load shedding, backoff आणि jitter सह retries, rate limiting आणि circuit breaking — आणि कोर्सचा संपूर्ण नकाशा. dist/demo.py मधील backpressure() आणि dist/sim.py मधील BoundedQueue.

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

प्रवेशाच्या दिवशी पुणे office मध्ये दर second ला 120 पालक येतात. कारकून दर second ला 100 जणांना मदत करू शकतात. प्रत्येक second ला आणखी 20 पालक रांगेत जोडले जातात.

कोणताही नियम नाही: रांग वाढतच जाते. 5 seconds नंतर नव्या पालकाला 1 second थांबावे लागते. 10 seconds नंतर 2 seconds. एका मिनिटानंतर ते कितीतरी जास्त होईल. मागच्या पालकांचा धीर सुटतो आणि ते पुन्हा येतात — त्यामुळे रांग आणखीच लांब होते. 😩
फाटकावर एक नियम: दीपिका दारात उभी असते. "रांगेत 200 जण बसतात. रांग भरली असेल, तर कृपया नंतर या." 🚧 काही पालकांना लगेच परत पाठवले जाते. पण आत असलेले सगळे जास्तीत जास्त सुमारे 1 second थांबतात, आणि कारकून कामाशी बरोबरी राखू शकतात.

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

आणि परत पाठवलेल्या पालकांसाठी आणखी एक नियम: सगळे एकाच क्षणी परत येऊ नका. थोडे थांबा, मग आणखी थोडे जास्त, आणि थोडासा random वेळ जोडा, म्हणजे पुढची गर्दी विखुरली जाईल.

🗺️ आकृती

flowchart LR
    in["👪 120 requests/s arrive"] --> gate{"🚧 queue full?<br/>limit 200"}
    gate -->|"yes"| shed["⛔ 429 / 503 + Retry-After<br/>shed 100 in 10 s"]
    gate -->|"no"| q["📋 bounded queue"]
    q --> srv["🧑‍💼 serve 100/s<br/>wait stays about 1.0 s"]
    un["unbounded queue: wait 1.0 s after 5 s,<br/>2.0 s after 10 s, and still growing"]

🗺️ रेखाटलेली आवृत्ती + एक lab: https://school-edh.pages.dev/distributed-systems/lesson-diagrams.html#l12

❓ काय

Overload — काम होऊ शकते त्यापेक्षा वेगाने येते. रांग दर second ला (arrival rate − service rate) इतकी वाढते; 120 आत आणि 100 बाहेर असतील, तर overload टिकेल तोपर्यंत दर second ला
Unbounded रांग — सगळे स्वीकारते. ती कधीच नकार देत नाही, त्यामुळे प्रत्येक request हळू होते, memory वाढते, आणि requests अनेकदा थांबल्यानंतर time out होतात — कोणासाठीच नसलेले काम. मग clients retry करतात, आणि load आणखी वाढतो.
Backpressure — व्यस्त भाग आपल्या आधीच्या भागाला हळू व्हायला किंवा पाठवणे थांबवायला सांगतो: भरलेली bounded रांग, नाकारलेली request, TCP flow control, जेवढे हाताळता येईल तेवढेच ओढून घेणारा consumer (Kafka consumers pull करतात).
Bounded रांग — एक कमाल लांबी; त्यापलीकडे नवे काम लगेच नाकारले जाते. स्वीकारलेल्या कामासाठीचे थांबणे सुमारे limit ÷ service rate पेक्षा कमी राहते.
Load shedding — बाकीच्यांचे संरक्षण करण्यासाठी काही काम जाणूनबुजून नाकारणे. सर्वात कमी महत्त्वाचे आधी टाका (payments च्या आधी analytics), आणि लवकर टाका — दारातच, अर्धे काम केल्यानंतर नव्हे.
429 Too Many Requests / 503 Service Unavailable + Retry-After — "नंतर या" सांगण्याचे HTTP मार्ग; Retry-After केव्हा ते सांगते (seconds मध्ये, किंवा तारीख).
Rate limiting — प्रत्येक client च्या rate वर मर्यादा (अनेकदा token bucket: tokens स्थिर rate ने पुन्हा भरतात, प्रत्येक request एक खर्च करते, छोटा burst साठवलेले tokens वापरू शकतो).
Exponential backoff आणि jitter सह retries — प्रत्येक failure नंतर जास्त वेळ थांबा (उदाहरणार्थ 100 ms, 200 ms, 400 ms … एका cap पर्यंत), आणि त्या संख्येपर्यंतचा random वेळ निवडा ("full jitter"), म्हणजे हजारो clients एकाच क्षणी retry करणार नाहीत. Retries ची संख्या मर्यादित ठेवा, किंवा retry budget ठेवा (उदाहरणार्थ, retries जास्तीत जास्त 10% requests).
Circuit breaker — एका dependency ला अनेक वेळा अपयश आल्यावर, काही काळ तिला call करणे थांबवा आणि लगेच fail करा; मग काही test requests जाऊ द्या.

🤔 का

कारण याआधीचा प्रत्येक धडा ताणाखाली जास्तीचे काम निर्माण करतो: timeouts नंतरचे retries (01, 11), failovers (05), repairs (06), elections (09). मर्यादा नसलेली system छोट्या overload चे पूर्ण overload मध्ये रूपांतर करते — रांग वाढते, प्रत्येक request time out होते, प्रत्येक client retry करतो, आणि load दुप्पट होतो. लवकर "नंतर या" सांगणे हेच बाकीची system चालू ठेवते.

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

dist/sim.py मधील BoundedQueue(limit) दर second ला एक tick चालवते: run(arrivals, served_per_tick) रिकाम्या जागेपर्यंत (limit - q; limit=None म्हणजे मर्यादा नाही) नव्या arrivals घेते, उरलेल्या shed मध्ये मोजते, served_per_tick पर्यंत serve करते, आणि थांबणे queue ÷ served_per_tick seconds म्हणून नोंदवते. dist/demo.py मधील backpressure() 100/s service विरुद्ध 120 requests/s चे 10 seconds चालवते, मर्यादेशिवाय आणि 200 च्या मर्यादेसह.

🧪 करून पाहा

python3 dist/demo.py backpressure
python3 - <<'EOF'
import sys; sys.path.insert(0, "dist"); from sim import BoundedQueue
for rate in (90, 120, 200):
    for limit in (None, 200, 400):
        q = BoundedQueue(limit); w = q.run([rate] * 10, served_per_tick=100)
        print(f"{rate:>3}/s arrive · limit {limit or 'none':>4} → wait after 10 s {w[-1]:>4.1f} s · shed {q.shed:>4}")
EOF
python3 dist/demo.py
python3 dist/test_dist.py

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

backpressure हे print करते:

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

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

 90/s arrive · limit none → wait after 10 s  0.0 s · shed    0
 90/s arrive · limit  200 → wait after 10 s  0.0 s · shed    0
 90/s arrive · limit  400 → wait after 10 s  0.0 s · shed    0
120/s arrive · limit none → wait after 10 s  2.0 s · shed    0
120/s arrive · limit  200 → wait after 10 s  1.0 s · shed  100
120/s arrive · limit  400 → wait after 10 s  2.0 s · shed    0
200/s arrive · limit none → wait after 10 s 10.0 s · shed    0
200/s arrive · limit  200 → wait after 10 s  1.0 s · shed  900
200/s arrive · limit  400 → wait after 10 s  3.0 s · shed  700

पूर्ण demo ✅ done — the branches agree ने संपतो, आणि tests 12/12 passed ने.

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

क्षमतेच्या खाली (90/s) मर्यादेला काहीच महत्त्व नसते. 200/s वर मर्यादा नसताना थांबणे 10 seconds मध्ये 10 seconds पर्यंत पोहोचले आणि अजूनही वाढत होते; 200 च्या मर्यादेसह ते 1 second वरच राहिले, 900 requests टाकून देण्याच्या किंमतीवर, ज्यांना झटपट "नंतर या" मिळाले. मर्यादा म्हणजे कमाल थांबण्याची निवड: इथे 400 सुमारे 3 seconds पर्यंत थांबू देते. ती user (किंवा caller चा timeout) खरोखर किती वेळ थांबेल त्यावरून निवडा.

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

service च्या आत unbounded in-memory queues
रांगेची मर्यादा इतकी मोठी की स्वीकारलेल्या requests serve होण्याआधीच time out होतात
backoff आणि jitter शिवाय लगेच retry करणे — "retry storm"
प्रत्येक थरावर retries (client, gateway, service): एका click साठी 3 × 3 × 3 = 27 प्रयत्न
overload साठी 429/503 + Retry-After ऐवजी 500 परत करणे, त्यामुळे clients ना "व्यस्त" आणि "बिघडलेले" यांतला फरक कळत नाही
चुकीचे काम टाकून देणे — analytics चालू असताना payments नाकारले जाणे

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

Edge वर rate limiting — प्रत्येक client address साठी token-bucket पद्धतीची मर्यादा असलेले NGINX, मर्यादा ओलांडल्यावर 429 उत्तर देते. On a real account:

limit_req_zone $binary_remote_addr zone=per_ip:10m rate=10r/s;
server {
    location /api/ {
        limit_req zone=per_ip burst=20 nodelay;
        limit_req_status 429;
        proxy_pass http://timetable;
    }
}

Load shed करणारी service केव्हा परत यायचे ते सांगते:

HTTP/1.1 503 Service Unavailable
Retry-After: 5

Envoy circuit breaking — प्रत्येक upstream cluster साठी connections, थांबलेल्या requests, active requests आणि active retries वर मर्यादा; मर्यादेपलीकडे Envoy request रांगेत ठेवण्याऐवजी लगेच fail करते (defaults 1024, 1024, 1024 आणि 3 आहेत):

clusters:
  - name: timetable
    circuit_breakers:
      thresholds:
        - priority: DEFAULT
          max_connections: 200
          max_pending_requests: 100      # the bounded queue
          max_requests: 400
          max_retries: 3

Code मध्ये backoff आणि full jitter सह retries:

import random, time
def call_with_retries(call, attempts=4, base=0.1, cap=5.0):
    for n in range(attempts):
        try:
            return call()
        except TemporaryError:
            if n == attempts - 1: raise
            time.sleep(random.uniform(0, min(cap, base * 2 ** n)))   # full jitter

AWS SDKs हे तुमच्यासाठी करतात (AWS_RETRY_MODE=standard किंवा adaptive); Kubernetes चा API server API Priority and Fairness ने load shed करतो आणि एखाद्या priority level च्या queues भरल्या की 429 उत्तर देतो.

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: प्रत्येक service साठी तिच्या रांगेच्या मर्यादा, भरल्यावर ती काय परत करते, कोणते काम ती आधी टाकून देते, आणि प्रत्येक caller ची retry policy लिहून ठेवा. मग क्षमतेपेक्षा जास्त load-test करा आणि 429/503 ची संख्या वाढत असताना p99 थांबणे सपाट राहते का ते तपासा.

🎓 शाखांचे एकमत झाले

निरोपे हरवतात, आणि शांततेतून जवळजवळ काहीच कळत नाही → प्रत्येक शाखेचे घड्याळ थोडेसे चुकीचे असते, म्हणून counters कारणाला परिणामाच्या आधी क्रम देतात → vector clocks खरा conflict आणि उशीर यांतला फरक ओळखतात → heartbeats फक्त संशय घेऊ शकतात → नोंदवहीच्या प्रतींना जे मिळालेच नव्हते ते हरवते → quorums सर्वात नवीन शोधण्यासाठी एकमेकांवर येतात → प्रत्येक वाचणाऱ्याला नाव असलेले वचन मिळते → तुटलेला रस्ता "नकार द्या किंवा जुने उत्तर द्या" ही निवड लादतो → बहुमत प्रत्येक term मध्ये एक leader निवडते → lease ला fencing token लागतो → at-least-once अधिक key म्हणजे effectively once → आणि bounded रांग लवकर "नंतर या" सांगते. तुम्ही फक्त distributed systems शिकला नाहीत — तुम्ही दोन boxes मधला कोणताही बाण पाहून योग्य प्रश्न विचारू शकता: ही चिठ्ठी हरवली, उशिरा आली, पुन्हा आली, किंवा रस्ता तुटला तर काय? 🌐👑🎓

⏭️ पुढे

इतर शाळा. System Design शाळा हे सगळे खऱ्या designs मध्ये वापरते; Scaling शाळा traffic हाताळते; Database शाळा नोंदवहीत आणखी खोलवर जाते; Kubernetes शाळा etcd आणि leases वर चालते; School portal मध्ये बाकी सगळे आहे.

git checkout main
python3 dist/demo.py     # one last run, for fun

🚧 Lesson 12 — Backpressure & the whole picture: say "try later" early

📍 You are here: Lesson 12 of 12 · Previous: lesson-11-exactly-once · The last lesson 🎓

📦 What's in this branch

Lessons 01–11, plus backpressure: when more work arrives than a node can do, an unbounded queue turns the overload into ever-growing waiting; a bounded queue refuses early with "try later" (429 / 503 + Retry-After) and keeps the wait short. Also load shedding, retries with backoff and jitter, rate limiting and circuit breaking — and the whole map of the course. backpressure() in dist/demo.py and BoundedQueue in dist/sim.py.

🧒 Explain like I'm 5

On admission day, 120 parents a second come to the Pune office. The clerks can help 100 a second. Every second, 20 more parents join the line.

No rule: the line grows and grows. After 5 seconds, a new parent waits 1 second. After 10 seconds, 2 seconds. After a minute it would be far longer. Parents at the back give up and come back — which makes the line even longer. 😩
A rule at the gate: Dipika stands at the door. "The line holds 200. If it is full, please come back later." 🚧 Some parents are turned away at once. But everyone inside waits at most about 1 second, and the clerks can keep up.

Turning some people away sounds unkind. But the other choice is that everyone waits too long, and the office stops working for all of them.

And one more rule for the parents sent away: do not all come back at the same moment. Wait a bit, then a bit longer, and add a small random wait, so the next crowd is spread out.

🗺️ Diagram

flowchart LR
    in["👪 120 requests/s arrive"] --> gate{"🚧 queue full?<br/>limit 200"}
    gate -->|"yes"| shed["⛔ 429 / 503 + Retry-After<br/>shed 100 in 10 s"]
    gate -->|"no"| q["📋 bounded queue"]
    q --> srv["🧑‍💼 serve 100/s<br/>wait stays about 1.0 s"]
    un["unbounded queue: wait 1.0 s after 5 s,<br/>2.0 s after 10 s, and still growing"]

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

❓ What

Overload — work arrives faster than it can be done. A queue grows by (arrival rate − service rate) every second; with 120 in and 100 out, that is 20 a second, for as long as the overload lasts.
Unbounded queue — accepts everything. It never refuses, so every request gets slower, memory grows, and requests often time out after waiting — work done for nobody. Then clients retry, and the load grows further.
Backpressure — the busy part tells the part before it to slow down or stop sending: a full bounded queue, a refused request, TCP flow control, a consumer that pulls only what it can handle (Kafka consumers pull).
Bounded queue — a maximum length; beyond it, new work is refused at once. The wait for accepted work stays below about limit ÷ service rate.
Load shedding — refusing some work on purpose to protect the rest. Shed the least important first (analytics before payments), and shed early — at the door, not after doing half the work.
429 Too Many Requests / 503 Service Unavailable + Retry-After — the HTTP ways to say "try later"; Retry-After says when (in seconds, or a date).
Rate limiting — cap each client's rate (often a token bucket: tokens refill at a steady rate, each request spends one, a short burst can use saved tokens).
Retries with exponential backoff and jitter — wait longer after each failure (for example 100 ms, 200 ms, 400 ms … up to a cap), and pick a random wait up to that number ("full jitter"), so thousands of clients do not retry at the same instant. Limit the number of retries, or keep a retry budget (for example, retries at most 10% of requests).
Circuit breaker — after many failures to one dependency, stop calling it for a while and fail fast; then let a few test requests through.

🤔 Why

Because every lesson before this one creates extra work under stress: retries after timeouts (01, 11), failovers (05), repairs (06), elections (09). A system with no limits turns a small overload into a total one — the queue grows, every request times out, every client retries, and the load doubles. Saying "try later" early is what keeps the rest of the system working.

🔧 How (in this repo)

BoundedQueue(limit) in dist/sim.py runs one tick per second: run(arrivals, served_per_tick) takes the new arrivals up to the free room (limit - q; limit=None means no limit), counts the rest in shed, serves up to served_per_tick, and records the wait as queue ÷ served_per_tick seconds. backpressure() in dist/demo.py runs 10 seconds of 120 requests/s against 100/s of service, with no limit and with a limit of 200.

🧪 Try it

python3 dist/demo.py backpressure
python3 - <<'EOF'
import sys; sys.path.insert(0, "dist"); from sim import BoundedQueue
for rate in (90, 120, 200):
    for limit in (None, 200, 400):
        q = BoundedQueue(limit); w = q.run([rate] * 10, served_per_tick=100)
        print(f"{rate:>3}/s arrive · limit {limit or 'none':>4} → wait after 10 s {w[-1]:>4.1f} s · shed {q.shed:>4}")
EOF
python3 dist/demo.py
python3 dist/test_dist.py

✅ Verify — what you should see

backpressure prints:

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

Your snippet prints:

 90/s arrive · limit none → wait after 10 s  0.0 s · shed    0
 90/s arrive · limit  200 → wait after 10 s  0.0 s · shed    0
 90/s arrive · limit  400 → wait after 10 s  0.0 s · shed    0
120/s arrive · limit none → wait after 10 s  2.0 s · shed    0
120/s arrive · limit  200 → wait after 10 s  1.0 s · shed  100
120/s arrive · limit  400 → wait after 10 s  2.0 s · shed    0
200/s arrive · limit none → wait after 10 s 10.0 s · shed    0
200/s arrive · limit  200 → wait after 10 s  1.0 s · shed  900
200/s arrive · limit  400 → wait after 10 s  3.0 s · shed  700

The full demo ends with ✅ done — the branches agree, and the tests with 12/12 passed.

🏁 What you just proved

Below capacity (90/s), the limit never matters. At 200/s with no limit, the wait reached 10 seconds in 10 seconds and was still growing; with a limit of 200 it stayed at 1 second, at the price of shedding 900 requests that got a fast "try later". The limit is a choice of maximum wait: 400 allows up to about 3 seconds here. Pick it from how long a user (or the caller's timeout) will really wait.

⚠️ Common mistakes

unbounded in-memory queues inside a service
a queue limit so large that accepted requests time out before they are served
retrying immediately, with no backoff and no jitter — a "retry storm"
retries at every layer (client, gateway, service): 3 × 3 × 3 = 27 attempts for one click
returning 500 for overload instead of 429/503 + Retry-After, so clients cannot tell "busy" from "broken"
shedding the wrong work — payments refused while analytics runs

🏭 In production

Rate limiting at the edge — NGINX with a token-bucket style limit per client address, answering 429 when it is exceeded. On a real account:

limit_req_zone $binary_remote_addr zone=per_ip:10m rate=10r/s;
server {
    location /api/ {
        limit_req zone=per_ip burst=20 nodelay;
        limit_req_status 429;
        proxy_pass http://timetable;
    }
}

A service that sheds load says when to come back:

HTTP/1.1 503 Service Unavailable
Retry-After: 5

Envoy circuit breaking — per upstream cluster, caps on connections, waiting requests, active requests and active retries; beyond a cap, Envoy fails the request at once instead of queueing it (the defaults are 1024, 1024, 1024 and 3):

clusters:
  - name: timetable
    circuit_breakers:
      thresholds:
        - priority: DEFAULT
          max_connections: 200
          max_pending_requests: 100      # the bounded queue
          max_requests: 400
          max_retries: 3

Retries with backoff and full jitter in code:

import random, time
def call_with_retries(call, attempts=4, base=0.1, cap=5.0):
    for n in range(attempts):
        try:
            return call()
        except TemporaryError:
            if n == attempts - 1: raise
            time.sleep(random.uniform(0, min(cap, base * 2 ** n)))   # full jitter

The AWS SDKs do this for you (AWS_RETRY_MODE=standard or adaptive); Kubernetes' API server sheds load with API Priority and Fairness and answers 429 when a priority level's queues are full.

🏭 Why this matters in production: for each service, write down its queue limits, what it returns when full, which work it sheds first, and the retry policy of every caller. Then load-test above capacity and check that the p99 wait stays flat while the 429/503 count rises.

🎓 The branches agree

Messengers get lost, and silence tells you almost nothing → every branch's clock is a little wrong, so counters order cause before effect → vector clocks tell a real conflict from a delay → heartbeats can only suspect → copies of the register lose what they had not received → quorums overlap to find the newest → each reader gets a named promise → a cut road forces "refuse or answer stale" → a majority elects one leader per term → a lease needs a fencing token → at-least-once plus a key is effectively once → and a bounded queue says "try later" early. You didn't just learn distributed systems — you can look at any arrow between two boxes and ask the right questions: what if this note is lost, late, repeated, or the road is cut? 🌐👑🎓

⏭️ Next

The other schools. The System Design school uses all of this in real designs; the Scaling school handles the traffic; the Database school goes deeper on the register; the Kubernetes school runs on etcd and leases; the School portal has the rest.

git checkout main
python3 dist/demo.py     # one last run, for fun

← Previousexactly once Finished! Take the quiz →check what stuck

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