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

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

🚦 धडा 12 — Rate limiting: कार्यालयाच्या खिडकीवरील बरणीतले tokens

📍 तुम्ही इथे आहात: 18 पैकी धडा 12 · पुढील: lesson-13-resilience

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

धडे 01–11, आणि लोंढ्यांपासून संरक्षण: loop मध्ये अडकलेले सदोष app, scraper, login हल्ला, किंवा फक्त खूप जास्त पाठवणारी एखादी शाळा. तुम्ही शिकता token bucket, leaky bucket, fixed आणि sliding windows, limit कुठे लागू करायचा (edge, gateway, API, प्रति user, प्रति key, global), 429 + Retry-After, आणि Redis मधील counters.

design/blocks.py — TokenBucket(rate, burst) आणि SlidingWindow(limit, window)
design/demo.py — python3 design/demo.py ratelimit
design/test_design.py — check L12

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

नियोजन कार्यालयात प्रश्नांसाठी एक खिडकी आहे. एके दिवशी एका पालकाच्या फोनमध्ये bug येतो. तो तोच प्रश्न पुन्हा पुन्हा, शेकडो वेळा विचारतो. इतर पालक खिडकीपर्यंत पोहोचूच शकत नाहीत.

ऐश्वर्या खिडकीवर tokens ची एक बरणी ठेवते. बरणीत जास्तीत जास्त 10 tokens मावतात. प्रत्येक प्रश्नाला एक token लागतो. एक मदतनीस बरणीत सेकंदाला 5 वेळा एक नवा token टाकतो. बरणी रिकामी झाली की उत्तर असते "कृपया थोडे थांबा" — error नाही, एक सभ्य थांबा.

म्हणजे पालक एकदम 10 झटपट प्रश्न विचारू शकतो (बरणीतले tokens), आणि मग त्यानंतर सुमारे सेकंदाला 5. सामान्य पालकाला बरणी कधी जाणवतही नाही. बिघडलेला फोन मंद केला जातो, आणि बाकी सगळ्यांचे काम होते.

कतरिना विचारते: "घड्याळाप्रमाणे सेकंदाला 10 असे का मोजत नाही?" ऐश्वर्या तिला दाखवते: 0.9 सेकंदाला 10 प्रश्न आणि 1.1 सेकंदाला आणखी 10. घड्याळाच्या प्रत्येक सेकंदात फक्त 10 आहेत. पण 0.2 सेकंदांत 20 आले. वेळेसोबत सरकणाऱ्या मोजणी-खिडकीत हे छिद्र नसते.

🗺️ आकृती

flowchart LR
    app["📱 parent's app<br/>12 requests at 0 s<br/>5 more at 0.5 s"]
    subgraph tb["🫙 token bucket: 5 per s, burst 10"]
      jar["10 tokens at start<br/>+2.5 by 0.5 s"]
    end
    subgraph sw["🪟 sliding window: 10 per 1 s"]
      log["log of the last 1 s<br/>still 10 at 0.5 s"]
    end
    app --> jar
    app --> log
    jar -->|"12 of 17 allowed"| api["🧩 notice API"]
    log -->|"10 of 17 allowed"| api
    jar -.->|"empty"| no["🚦 429 Too Many Requests<br/>Retry-After: 1"]

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

❓ काय

Rate limit — ठराविक वेळेत caller जास्तीत जास्त किती requests पाठवू शकतो. Limit ओलांडली की server कोणतेही खरे काम करण्याआधी पटकन आणि स्वस्तात नकार देतो.
Token bucket — bucket मध्ये जास्तीत जास्त burst tokens मावतात आणि ते सेकंदाला rate tokens ने भरते. प्रत्येक request एक token घेते. हे आधी छोटा burst, मग स्थिर rate चालू देते. बहुतेक API gateways हेच वापरतात.
Leaky bucket — requests एका queue मध्ये थांबतात जी ठराविक वेगाने रिकामी होते; queue भरली की नव्या requests टाकून दिल्या जातात. बाहेर येणारा प्रवाह अगदी एकसारखा असतो, जो हळू downstream ला वाचवतो (उदाहरणार्थ सेकंदाला 50 messages स्वीकारणारा SMS provider).
Fixed window — घड्याळाच्या प्रत्येक कालावधीत requests मोजा (प्रति मिनिट, :00 ते :59). एक counter, खूप स्वस्त. त्याचे छिद्र: एका window च्या शेवटी आणि पुढच्या window च्या सुरुवातीला आलेला burst limit च्या दुप्पट असू शकतो.
Sliding window — प्रत्येक क्षणी मागच्या window seconds मधल्या requests मोजा. Log (प्रत्येक request साठी एक नोंद, या repo प्रमाणे) अचूक असतो पण प्रत्येक request साठी memory वापरतो. Sliding window counter दोन fixed windows वजनानुसार मिसळतो — जवळजवळ अचूक, फक्त दोन counters.
कुठे लागू करायचे — थरांमध्ये, सर्वात स्वस्त आधी:
- edge / WAF — प्रति IP address, लोंढे आणि bots विरुद्ध;
- API gateway — प्रति API key किंवा client (दिवसाच्या quota सह usage plan);
- API — प्रति user (parent id), आणि प्रति endpoint अधिक कडक (login: मिनिटाला 5 प्रयत्न; तातडीची सूचना post करणे: दिवसाला काही);
- global — सामाईक resource वाचवा: database, किंवा SMS provider चा quota.
429 Too Many Requests — "हळू" साठीचा status code. Retry-After जोडा (seconds, किंवा तारीख) म्हणजे चांगल्या clients ना पुन्हा कधी प्रयत्न करायचा ते कळते. अनेक APIs उरलेले budget पण पाठवतात (RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset, किंवा जुनी X-RateLimit-* नावे).
Redis मधील counters — 12 API servers (धडा 02) असताना, प्रत्येक server मधील counter मुळे caller ला limit च्या 12 पट मिळते. Counters एकाच सामाईक ठिकाणी ठेवा — Redis — आणि ते atomically update करा (INCR, किंवा छोटी Lua script).
Fail open की fail closed — Redis बंद असेल तर सगळ्या requests ना परवानगी द्यायची (open) की सगळ्या नाकारायच्या (closed)? बहुतेक APIs साठी: local, थोडी सैल limit ठेवून open fail करा. Login आणि payments साठी: अधिक कडक राहा.

🤔 का

कारण एका caller ने बाकी सगळ्यांकडून service हिसकावून घेता कामा नये. धडा 02 ने app चे माप peak ला 3,507 req/s असे ठरवले — सगळ्यांसाठी मिळून. Limit नसेल तर retry loop मधील एकटे app एवढ्यापेक्षा जास्त पाठवू शकते. Limit पैसे पण वाचवते: 5M तातडीच्या SMS ला खरे पैसे लागतात, आणि चोरलेल्या शिक्षिका-account ने ते दहा वेळा पाठवता कामा नयेत.

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

design/blocks.py मध्ये:

TokenBucket(rate, burst).allow(t) (t − last) × rate tokens जोडतो (burst पर्यंत), मग token असेल तर एक घेतो.
SlidingWindow(limit, window).allow(t) परवानगी दिलेल्या वेळांचा log ठेवतो, t − window पेक्षा जुन्या काढून टाकतो, आणि limit पेक्षा कमी उरल्या असतील तर परवानगी देतो.

design/demo.py मधील ratelimit() t = 0 s ला 12 requests आणि t = 0.5 s ला 5 requests दोन्हींमधून पाठवतो. खालचा snippet edge वरचे छिद्र दाखवण्यासाठी, inline लिहिलेला एक छोटा fixed-window counter जोडतो.

🧪 करून पाहा

python3 design/demo.py ratelimit
python3 - <<'EOF'
import sys; sys.path.insert(0, "design"); from blocks import TokenBucket, SlidingWindow
burst = [0.0] * 12 + [0.5] * 5
for rate, b in ((5, 10), (5, 20), (10, 10), (1, 5)):
    tb = TokenBucket(rate, b); print(f"token bucket rate {rate:>2}/s burst {b:>2} → {sum(tb.allow(t) for t in burst):>2} of 17")
steady = [i * 0.1 for i in range(30)]          # one request every 100 ms for 3 s = 10 per second
tb, sw = TokenBucket(5, 10), SlidingWindow(10, 1.0)
print("steady 10/s for 3 s → bucket", sum(tb.allow(t) for t in steady), "of 30 · window", sum(sw.allow(t) for t in steady), "of 30")
edge = [0.9] * 10 + [1.1] * 10                  # 10 just before a minute-mark, 10 just after
def fixed(times, limit=10, window=1.0):
    counts, ok = {}, 0
    for t in times:
        k = int(t // window)
        if counts.get(k, 0) < limit: counts[k] = counts.get(k, 0) + 1; ok += 1
    return ok
sw = SlidingWindow(10, 1.0)
print("20 requests around t=1.0 s → fixed window lets", fixed(edge), "in 0.2 s · sliding window lets", sum(sw.allow(t) for t in edge))
EOF

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

ratelimit हे छापतो:

── one parent's app sends 12 requests at t=0 s and 5 more at t=0.5 s
   token bucket (5/s, burst 10) → 12 of 17 allowed · sliding window (10 per 1 s) → 10 of 17
   the bucket refilled 2.5 tokens in 0.5 s, so 2 more got in; the window still counts the first 10 until t=1.0 s
   token bucket: smooth rate + a burst allowance · window: a hard count per period
   limit per user, per API key and globally; answer 429 with Retry-After; keep the counters in Redis

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

token bucket rate  5/s burst 10 → 12 of 17
token bucket rate  5/s burst 20 → 17 of 17
token bucket rate 10/s burst 10 → 15 of 17
token bucket rate  1/s burst  5 →  5 of 17
steady 10/s for 3 s → bucket 24 of 30 · window 30 of 30
20 requests around t=1.0 s → fixed window lets 20 in 0.2 s · sliding window lets 10

Tests मध्ये ✅ L12 the token bucket refills, the window still counts असते.

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

Burst पहिला क्षण ठरवतो (10 tokens → एकदम 10; 20 → सगळ्या 17 जातात), आणि rate पुढचे ठरवतो (10/s हा 0.5 s मध्ये 5 tokens भरतो → 15). सेकंदाला स्थिर 10 हे "सेकंदाला 10" window साठी ठीक आहे (30 पैकी 30), पण 5/s चे bucket फक्त 24 आत सोडते: burst क्षणभर ही तफावत लपवतो, मग rate चे राज्य चालते. आणि fixed window ने दोन windows च्या सीमेवर 0.2 s मध्ये 20 requests आत सोडल्या — त्याच्या limit च्या दुप्पट; sliding window ने 10 सोडल्या.

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

सामाईक counter ऐवजी प्रत्येक server ची limit — 12 servers, limit च्या 12 पट
फक्त प्रति-IP limit — एका NAT address मागची संपूर्ण शाळा ती वाटून घेते, आणि अनेक addresses असलेला हल्लेखोर वाटून घेत नाही
प्रत्येक endpoint साठी एकच limit — login आणि "तातडीची सूचना पाठवा" यांना खूप कडक limits लागतात
Retry-After शिवाय 429 — clients अंदाज करतात, आणि अनेकदा "लगेच" असा अंदाज करतात
backoff आणि jitter शिवाय 429 लगेच retry करणारे clients (धडा 13)
Redis मध्ये आधी वाचा-मग लिहा counters (GET, मग SET) — दोन servers शर्यत लावतात; INCR किंवा Lua वापरा
paid provider ला (SMS, email, AI model) तुम्ही करत असलेल्या calls वर कोणतीही limit नसणे

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

खऱ्या account वर — API Gateway usage plan: token bucket (rate + burst) आणि प्रति API key रोजचा quota:

aws apigateway create-usage-plan --name parents-app \
    --throttle burstLimit=10,rateLimit=5 \
    --quota limit=100000,period=DAY \
    --api-stages apiId=a1b2c3d4e5,stage=prod

Edge वर AWS WAF rate-based rule — 5 मिनिटांत 2,000 पेक्षा जास्त requests पाठवणारा IP address block करा (web ACL च्या Rules चा भाग):

{ "Name": "per-ip-flood", "Priority": 1, "Action": { "Block": {} },
  "Statement": { "RateBasedStatement": { "Limit": 2000, "EvaluationWindowSec": 300, "AggregateKeyType": "IP" } },
  "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "per-ip-flood" } }

API समोर NGINX — प्रति client address एक leaky bucket, burst सह, 429 उत्तर देणारा:

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

Redis मध्ये प्रत्येक पालकासाठी sliding-window log, एकाच Lua script मध्ये atomic (keys आपोआप expire होतात):

-- KEYS[1] = "rl:parent:42"  ARGV = now_ms, window_ms, limit, request_id
redis.call("ZREMRANGEBYSCORE", KEYS[1], 0, ARGV[1] - ARGV[2])
if redis.call("ZCARD", KEYS[1]) < tonumber(ARGV[3]) then
  redis.call("ZADD", KEYS[1], ARGV[1], ARGV[4])
  redis.call("PEXPIRE", KEYS[1], ARGV[2])
  return 1
end
return 0

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: limits API करारात (धडा 03) एका table च्या स्वरूपात लिहा: प्रति IP, प्रति key, प्रति user, प्रति endpoint, global. मग 429 उत्तरांच्या संख्येचा graph काढा. अचानक वाढ म्हणजे एकतर हल्ला किंवा खऱ्या पालकांसाठी खूप कडक limit — दोन्हींमध्ये एखाद्या माणसाने पाहायला हवे.

⏭️ पुढे

Limits बाहेरून येणारे लोंढे थांबवतात. पण आतला एखादा भाग अपयशी झाला तर — photo service, database, संपूर्ण data centre? Design मधूनच resilience.

git checkout lesson-13-resilience

🚦 Lesson 12 — Rate limiting: tokens in a jar at the office window

📍 You are here: Lesson 12 of 18 · Next: lesson-13-resilience

📦 What's in this branch

Lessons 01–11, plus protection against floods: a buggy app in a loop, a scraper, a login attack, or simply one school that sends too much. You learn the token bucket, the leaky bucket, fixed and sliding windows, where to enforce a limit (edge, gateway, API, per user, per key, global), 429 + Retry-After, and counters in Redis.

design/blocks.py — TokenBucket(rate, burst) and SlidingWindow(limit, window)
design/demo.py — python3 design/demo.py ratelimit
design/test_design.py — check L12

🧒 Explain like I'm 5

The planning office has one window for questions. One day a parent's phone has a bug. It asks the same question again and again, hundreds of times. Other parents cannot reach the window.

Aishwarya puts a jar of tokens at the window. The jar holds at most 10 tokens. Every question costs one token. A helper drops a new token into the jar 5 times a second. When the jar is empty, the answer is "please wait a moment" — not an error, a polite stop.

So a parent can ask 10 quick questions at once (the tokens in the jar), and then about 5 a second after that. A normal parent never notices the jar. The broken phone is slowed down, and everyone else is served.

Katrina asks: "Why not just count 10 per second on the clock?" Aishwarya shows her: 10 questions at 0.9 seconds and 10 more at 1.1 seconds. Each clock second has only 10. But 20 arrived in 0.2 seconds. A counting window that slides with time does not have this hole.

🗺️ Diagram

flowchart LR
    app["📱 parent's app<br/>12 requests at 0 s<br/>5 more at 0.5 s"]
    subgraph tb["🫙 token bucket: 5 per s, burst 10"]
      jar["10 tokens at start<br/>+2.5 by 0.5 s"]
    end
    subgraph sw["🪟 sliding window: 10 per 1 s"]
      log["log of the last 1 s<br/>still 10 at 0.5 s"]
    end
    app --> jar
    app --> log
    jar -->|"12 of 17 allowed"| api["🧩 notice API"]
    log -->|"10 of 17 allowed"| api
    jar -.->|"empty"| no["🚦 429 Too Many Requests<br/>Retry-After: 1"]

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

❓ What

Rate limit — the most requests a caller may send in some time. Over the limit, the server refuses quickly and cheaply, before any real work.
Token bucket — a bucket holds up to burst tokens and refills at rate tokens per second. Each request takes one. It allows a short burst, then a steady rate. Most API gateways use it.
Leaky bucket — requests wait in a queue that drains at a fixed rate; when the queue is full, new requests are dropped. The output is perfectly smooth, which protects a slow downstream (for example an SMS provider that accepts 50 messages a second).
Fixed window — count requests per clock period (per minute, from :00 to :59). One counter, very cheap. Its hole: a burst at the end of one window and the start of the next can be twice the limit.
Sliding window — count requests in the last window seconds at every moment. A log (one entry per request, as in this repo) is exact but uses memory per request. A sliding window counter mixes two fixed windows by weight — nearly exact, two counters only.
Where to enforce — in layers, cheapest first:
- edge / WAF — per IP address, against floods and bots;
- API gateway — per API key or client (a usage plan with a quota per day);
- the API — per user (a parent id), and stricter per endpoint (login: 5 tries a minute; posting an urgent notice: a few a day);
- global — protect a shared resource: the database, or the SMS provider's quota.
429 Too Many Requests — the status code for "slow down". Add Retry-After (seconds, or a date) so good clients know when to try again. Many APIs also send the remaining budget (RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset, or the older X-RateLimit-* names).
Counters in Redis — with 12 API servers (lesson 02), a counter inside each server lets a caller get 12 times the limit. Keep the counters in one shared place — Redis — and update them atomically (INCR, or a small Lua script).
Fail open or fail closed — if Redis is down, do you allow all requests (open) or refuse all (closed)? For most APIs: fail open with a local, looser limit. For login and payments: be stricter.

🤔 Why

Because one caller must not be able to take the service from everyone else. Lesson 02 sized the app for 3,507 req/s at peak — for everyone. A single app in a retry loop, with no limit, can send more than that alone. A limit also protects money: 5M urgent SMS cost real money, and a stolen teacher account must not be able to send them ten times.

🔧 How (in this repo)

In design/blocks.py:

TokenBucket(rate, burst).allow(t) adds (t − last) × rate tokens (up to burst), then takes one if it has one.
SlidingWindow(limit, window).allow(t) keeps a log of the times it allowed, drops those older than t − window, and allows if fewer than limit remain.

ratelimit() in design/demo.py sends 12 requests at t = 0 s and 5 at t = 0.5 s through both. The snippet below adds a small fixed-window counter, written inline, to show the edge hole.

🧪 Try it

python3 design/demo.py ratelimit
python3 - <<'EOF'
import sys; sys.path.insert(0, "design"); from blocks import TokenBucket, SlidingWindow
burst = [0.0] * 12 + [0.5] * 5
for rate, b in ((5, 10), (5, 20), (10, 10), (1, 5)):
    tb = TokenBucket(rate, b); print(f"token bucket rate {rate:>2}/s burst {b:>2} → {sum(tb.allow(t) for t in burst):>2} of 17")
steady = [i * 0.1 for i in range(30)]          # one request every 100 ms for 3 s = 10 per second
tb, sw = TokenBucket(5, 10), SlidingWindow(10, 1.0)
print("steady 10/s for 3 s → bucket", sum(tb.allow(t) for t in steady), "of 30 · window", sum(sw.allow(t) for t in steady), "of 30")
edge = [0.9] * 10 + [1.1] * 10                  # 10 just before a minute-mark, 10 just after
def fixed(times, limit=10, window=1.0):
    counts, ok = {}, 0
    for t in times:
        k = int(t // window)
        if counts.get(k, 0) < limit: counts[k] = counts.get(k, 0) + 1; ok += 1
    return ok
sw = SlidingWindow(10, 1.0)
print("20 requests around t=1.0 s → fixed window lets", fixed(edge), "in 0.2 s · sliding window lets", sum(sw.allow(t) for t in edge))
EOF

✅ Verify — what you should see

ratelimit prints:

── one parent's app sends 12 requests at t=0 s and 5 more at t=0.5 s
   token bucket (5/s, burst 10) → 12 of 17 allowed · sliding window (10 per 1 s) → 10 of 17
   the bucket refilled 2.5 tokens in 0.5 s, so 2 more got in; the window still counts the first 10 until t=1.0 s
   token bucket: smooth rate + a burst allowance · window: a hard count per period
   limit per user, per API key and globally; answer 429 with Retry-After; keep the counters in Redis

Your snippet prints:

token bucket rate  5/s burst 10 → 12 of 17
token bucket rate  5/s burst 20 → 17 of 17
token bucket rate 10/s burst 10 → 15 of 17
token bucket rate  1/s burst  5 →  5 of 17
steady 10/s for 3 s → bucket 24 of 30 · window 30 of 30
20 requests around t=1.0 s → fixed window lets 20 in 0.2 s · sliding window lets 10

The tests include ✅ L12 the token bucket refills, the window still counts.

🏁 What you just proved

The burst decides the first moment (10 tokens → 10 at once; 20 → all 17 pass), and the rate decides what follows (10/s refills 5 tokens in 0.5 s → 15). A steady 10 per second is fine for a window of "10 per second" (30 of 30), but a bucket of 5/s lets only 24 through: the burst hides the gap for a moment, then the rate rules. And the fixed window let 20 requests in 0.2 s — twice its limit — at the edge of two windows; the sliding window let 10.

⚠️ Common mistakes

a limit per server instead of a shared counter — 12 servers, 12 times the limit
only a per-IP limit — a whole school behind one NAT address shares it, and an attacker with many addresses does not
the same limit for every endpoint — login and "send urgent notice" need much stricter ones
429 without Retry-After — clients guess, and often guess "at once"
clients that retry a 429 at once, with no backoff and jitter (lesson 13)
read-then-write counters in Redis (GET, then SET) — two servers race; use INCR or Lua
no limit on the calls you make to a paid provider (SMS, email, an AI model)

🏭 In production

On a real account — an API Gateway usage plan: a token bucket (rate + burst) and a daily quota per API key:

aws apigateway create-usage-plan --name parents-app \
    --throttle burstLimit=10,rateLimit=5 \
    --quota limit=100000,period=DAY \
    --api-stages apiId=a1b2c3d4e5,stage=prod

AWS WAF rate-based rule at the edge — block an IP address that sends more than 2,000 requests in 5 minutes (part of a web ACL's Rules):

{ "Name": "per-ip-flood", "Priority": 1, "Action": { "Block": {} },
  "Statement": { "RateBasedStatement": { "Limit": 2000, "EvaluationWindowSec": 300, "AggregateKeyType": "IP" } },
  "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "per-ip-flood" } }

NGINX in front of the API — a leaky bucket per client address, with a burst, answering 429:

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

A sliding-window log per parent in Redis, atomic in one Lua script (keys expire by themselves):

-- KEYS[1] = "rl:parent:42"  ARGV = now_ms, window_ms, limit, request_id
redis.call("ZREMRANGEBYSCORE", KEYS[1], 0, ARGV[1] - ARGV[2])
if redis.call("ZCARD", KEYS[1]) < tonumber(ARGV[3]) then
  redis.call("ZADD", KEYS[1], ARGV[1], ARGV[4])
  redis.call("PEXPIRE", KEYS[1], ARGV[2])
  return 1
end
return 0

🏭 Why this matters in production: write the limits into the API contract (lesson 03) as a table: per IP, per key, per user, per endpoint, global. Then graph the number of 429 answers. A sudden rise is either an attack or a limit that is too tight for real parents — both need a person to look.

⏭️ Next

Limits stop floods from outside. But what happens when a part inside fails — the photo service, the database, a whole data centre? Resilience by design.

git checkout lesson-13-resilience

← Previousdistributed transactions Next →resilience

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