Visual intuition: Retry & backoff sequence¶

Caption: Retry logic applies exponential backoff with jitter to avoid thundering herds.

Alt: Sequence diagram showing client requests, retry attempts, server failures, backoff waits, and eventual success.

HTTP Requests and Responses — resilient client patterns¶

Business framing: Reliable HTTP clients are the connective tissue between your services and external data sources. This section covers status codes, idempotency, retries, rate limiting, and safe fallback strategies illustrated with Pyodide-safe simulated requests.

Learning objectives¶

• Interpret common HTTP status codes and choose correct client actions.

• Implement retries with exponential backoff and jitter.

• Design idempotent operations and safe fallbacks for unreliable endpoints.

Pyodide-safe simulated HTTP helper with exponential backoff + jitter¶

Idempotency note¶

• Use idempotency keys for operations that must be safe to repeat (payments, order creation retries).

• Design server endpoints to accept a client-generated idempotency token and return a consistent result when re-sent.

MCQ¶

• Q: Which status code typically indicates the client should not retry without change?

  • A) 400

  • B) 500

  • C) 429

  • (Answer: A)

Exercises¶

1. Implement retry_with_backoff with a maximum total wait time cap and a callback for logging attempts.

2. Add a simple rate_limit decorator that allows N calls per second to an inner function.

3. (Stretch) Simulate an idempotent POST endpoint by storing idempotency keys in an in-memory dict and returning the stored result on repeated calls.

Notes: Inserted examples are deterministic and safe to run in-browser. I preserved existing notebook content and left heavy network calls out of runnable examples.

HTTP Requests and Responses¶