1 min lesson
Rate limits and pagination
Choose two examples from the table in "Rate limits and pagination" and explain what each teaches you to do.
Step 1 of 2
Rate limits and paginationthe two things candidates get wrong
GitHub gives you a primary hourly budget plus an opaque secondary rate limit that punishes bursts and concurrency. Respect both. Read the limit headers, throttle proactively with a token bucket and back off when told to.
- Failure
- Primary rate limit (403/429 + reset header)
- Naive handling
- Retry immediately in a loop
- Resilient handling
- Honor the reset time, throttle via token bucket, queue non-urgent work
- Failure
- Secondary rate limit (abuse detection)
- Naive handling
- Hammer harder with parallel calls
- Resilient handling
- Add
Retry-Afterbackoff with jitter, drop concurrency, serialize the offender
- Failure
- Pagination
- Naive handling
- Fetch page 1 and assume it's complete
- Resilient handling
- Iterate cursor/Link headers to exhaustion behind an async iterator
- Failure
- Partial outage (provider 5xx)
- Naive handling
- Surface the 5xx to the user
- Resilient handling
- Serve cached data if fresh enough, queue the write, retry with backoff
| Failure | Naive handling | Resilient handling |
|---|---|---|
| Primary rate limit (403/429 + reset header) | Retry immediately in a loop | Honor the reset time, throttle via token bucket, queue non-urgent work |
| Secondary rate limit (abuse detection) | Hammer harder with parallel calls | Add Retry-After backoff with jitter, drop concurrency, serialize the offender |
| Pagination | Fetch page 1 and assume it's complete | Iterate cursor/Link headers to exhaustion behind an async iterator |
| Partial outage (provider 5xx) | Surface the 5xx to the user | Serve cached data if fresh enough, queue the write, retry with backoff |
The resilient column is what "resilient abstraction" means in the JD.
Learn more
Full explanation
Graceful degradation
Graceful degradationtheir outage is not your outage
GitHub has bad days. When a provider degrades, the rest of Cursor should keep working. Reads fall back to cache; writes get queued and replayed; only the directly affected feature shows a soft failure.
- Cache reads (repo metadata, recent diffs) with a TTL so a provider blip serves slightly stale instead of nothing.
- Queue writes (comments, PR creation) and replay them when the provider recovers, with idempotency so replays don't duplicate.
- Wrap each provider in a circuit breaker so a hung GitHub doesn't exhaust your connection pool and starve unrelated features.
- Show a scoped, honest degraded state in the UI rather than a generic crash.
Learn more
Optional practice
Test yourself on Rate limits and pagination
QGitHub starts returning intermittent 5xx errors for one of its endpoints. Walk through how your SCM abstraction keeps Cursor usable.