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
Practice: Rate limits and pagination
QGitHub starts returning intermittent 5xx errors for one of its endpoints. Walk through how your SCM abstraction keeps Cursor usable.