Resilience LineLesson
Rate limiting — a budget for each caller
A rate limit gives each client its own budget — a steady rate plus a burst — so one client's flood gets fast 429s while the others carry on. It shares the service fairly; it protects capacity only if the limits come from what the servers can really handle.
12 minMediumStation: Rate limitingMembers lesson
Membership isn’t open yet. The free lessons are open — 16 of them.
- Partner app A (a bug loops its calls)Users
- Partner app B (normal)Users
- Product API serverWeb API
What you'll be able to do
- 1Explain how a token bucket's refill rate and burst size decide which requests get through.
- 2Predict what each client sees when one client floods a service behind a single shared limit, and behind per-client limits.
- 3Choose a limit's key, rate and burst from tested capacity, and how a client should react to a 429.
Inside the lesson
- steps
- 9
- questions
- 8
- simulations
- 4
You guess first, then run the system and see if you were right.
Step 1 · The setup
At the last stop, a full queue pushed back on its sender. This time the trouble is one caller among many.
Checkout's product API serves partner apps, each with its own API key. Its server takes about 92 requests a second. App A normally sends 20 a second and app B 30. At t = 10 a bug makes app A loop its calls — 200 a second.
Steps 2–9 are for members