Phase 3: How the Internet & APIs Actually Work · ~35 minutes · Python · requests

Rate Limits, Retries, and Real-World API Etiquette

Retrying a failed request immediately, in a tight loop, is the exact behavior a rate limit exists to stop — you're not working around the problem, you're feeding it.

Hiring signal: Implements exponential backoff correctly and knows exactly which operations are safe to retry and which aren't

What you will learn

Explain rate limiting as deliberate server behavior, not a bug to work around
Implement exponential backoff as the standard polite-retry pattern
Explain idempotency and why retrying a payment call is dangerous while retrying a read call isn't
Calculate a safe request pace from a documented rate limit

Introduction

Type: Learn Languages: Python Prerequisites: Lesson 04 (async/await in Practice) Time: ~35 minutes

Objective

Learning objectives

Explain rate limiting as deliberate server behavior, not a bug to work around
Implement exponential backoff as the standard polite-retry pattern
Explain idempotency and why retrying a payment call is dangerous while retrying a read call isn't
Calculate a safe request pace from a documented rate limit

What you're building

A script (resilient_client.py) that:

Implements call_with_retry (or your own equivalent) using real exponential backoff, following this lesson's formula
Tests it against a simulated API (a small class or function of your own, following this lesson's FakeRateLimitedAPI pattern) that fails a known number of times before succeeding, and confirms it eventually succeeds with the correct number of attempts
Contains a comment identifying, for two operations of your choosing, whether each is naturally idempotent (safe to retry blindly) or not (needs an idempotency key or different handling), and why
Given a documented rate limit of your choosing (e.g., "100 requests per minute"), calculates and states the safe steady pace in a comment

An API documents a limit of "10 requests per second." Your script currently sends requests as fast as it can, in a tight loop with no delay. What's the most accurate assessment?

A tight loop with no delay sends requests as fast as the network and CPU allow — typically hundreds or thousands per second, wildly exceeding a 10-per-second limit almost instantly, regardless of the total request count planned. The fix is exactly this lesson's pacing calculation: 10 requests per second means roughly one request every 0.1 seconds is the steady-state safe pace, not 'as fast as possible until told to stop.' Rate limits apply to requests sent, not just failures — sending too fast is what CAUSES the 429s in the first place, not a separate concern from them.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers The Problem, Check Yourself, Key Terms & Next — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.