Skip to content
Ameen Abozaid
Englishالعربية
MID-034

Rate limiting

  • 6 Lessons
  • 2 h practice (estimate)
Start module
On this page 8 topics

Overview

Topics

  • Token bucket
  • leaky bucket
  • quotas
  • client throttling

Learn first

2 h of practice (estimate)

Learning outcomes

  1. Explain token bucket, leaky bucket, and window algorithms.
  2. Implement per-client rate limiting with correct 429 responses and Retry-After.
  3. Distinguish rate limits, quotas, and load shedding.
  4. Behave well as a client of a rate-limited API.

Lessons

  1. 01Why limit
  2. 02Token and leaky buckets
  3. 03Distributed rate limiting
  4. 04Quotas and load shedding
  5. 05Being a good client
  6. 06Demo: per-customer limits at the edge

Lab and exercises

Lab

MID-034-LAB1 · Fair use

Outcomes: 1–4 · Time: ~2 h Add per-customer and per-IP limits to search and checkout (at the gateway or in the service, using a shared store so limits hold across replicas). Return 429 with Retry-After. Use different limits for search (generous) and checkout (strict). Write a small client that honors Retry-After.

Acceptance: a load test shows one abusive client cannot degrade others: normal clients keep their latency and success rate while the abuser receives 429s.

Exercises (assessment: quiz plus lab)

IDOutcomeTask
MID-034-EX011Simulate a token bucket (rate 2/s, capacity 5) for 10 requests arriving at once; state how many pass.
MID-034-EX021Explain the fixed-window double-burst problem with numbers and how a sliding window fixes it.
MID-034-EX032Write a Spring OncePerRequestFilter or gateway config returning 429 with Retry-After.
MID-034-EX042Explain why an in-memory limiter fails behind a load balancer and give two fixes.
MID-034-EX053Classify as rate limit, quota, or load shedding: 100 req/s per key; 10,000 calls per month; reject recommendation calls at 95% CPU.
MID-034-EX064Write client code that retries on 429 honoring Retry-After, with a cap.
Show solutions
  • EX01 Bucket starts full: 5 pass, 5 are rejected; about 2 more pass each following second.
  • EX02 Limit 100/min: 100 requests at 12:00:59 and 100 at 12:01:00 give 200 in two seconds. A sliding window counts the last 60 s so the second burst is rejected.
  • EX03 Filter checks the limiter for the key, sets 429, header Retry-After: <seconds>, and a JSON body; otherwise continues the chain.
  • EX04 Each instance counts separately so the limit multiplies by instance count. Fix: shared Redis counter with an atomic script, or enforce at a single gateway layer.
  • EX05 Rate limit; quota; load shedding.
  • EX06 Loop up to 3 attempts; on 429 parse Retry-After (seconds), sleep that long (plus small jitter), else exponential backoff; give up after the cap.

Outcome 1 is also checked by quiz Q02 to Q04.

Quiz

Outcomes: O1 algorithms · O2 implementation and 429 · O3 limits, quotas, shedding · O4 good clients.

A self-check for you: nothing is graded, saved or sent anywhere. Choose an answer, then check it. You can try again as often as you like.

  1. 1A token bucket allows:O1
  2. 2The fixed-window weakness is:O1
  3. 3A leaky bucket mainly:O1
  4. 4Correct status when a client exceeds its rate:O2
  5. 5Retry-After tells the client:O2
  6. 6In-memory limiting behind 3 instances effectively allows:O2
  7. 7A monthly plan allowance is a:O3
  8. 8Load shedding reacts to:O3
  9. 9On 429 a good client:O4
  10. 10To reduce calls to a limited API:O4

Practical part

Six exercises MID-034-EX01 to EX06 plus MID-034-LAB1. Pass: at least five exercises, 8 of 10 quiz answers, and a load test where one abusive client does not degrade others.

Common mistakes

In-memory limits behind a load balancer; no Retry-After.

Assessment

Quiz plus lab.

Career relevance

Abuse prevention (MID-052) and API management (ARC-025).

Type to search levels, phases, modules and lessons.