Designing for Rate Limits and Pagination
Protect an API from abuse with a real rate limiter and standardized RateLimit response headers, and replace fragile offset pagination with stable, opaque cursors — the two things almost every public API needs before real traffic shows up.
Prerequisites: a working API with at least one collection endpoint (the task API from the first project works well); Redis or comfort with an in-memory equivalent for the rate limiter.
Version note: verified against draft-ietf-httpapi-ratelimit-headers-11 (IETF Internet-Draft, published 23 May 2026, expires 24 November 2026) and RFC 8288 (Web Linking). The rate-limit header spec is still an active draft, not an RFC — its current version (-11) defines a single combined RateLimit field plus an optional RateLimit-Policy field, which is a format change from earlier draft versions that used three separate fields (RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset). Those three separate field names are not officially standardized but remain extremely widely deployed as a de facto convention (GitHub, GitLab, and many others use them), so this project shows both and explains when you'd reach for each.
Both rate limits and pagination exist to make a shared resource — your server's capacity, or a large result set — behave predictably for every client instead of letting one client's usage pattern degrade the experience for everyone else. Rate limits bound how often a client can call you; pagination bounds how much any single call can cost.
This project adds both to the task API: a token-bucket limiter with standards-based headers, and cursor-based pagination on the task list endpoint.
Test what you just learned
Self-testing is one of the best ways to retain new skills. Unlock project quizzes to check your understanding.
Log in to unlock0 / 7 complete