Which practice helps avoid service disruption when consuming GitHub APIs at scale?

Question

Options

• ADesigning your application to work within GitHub's rate limits
• BUsing multiple tokens to bypass limits
• CCaching all API responses permanently
• DIgnoring secondary rate limits

• A
  93% (62)
• B
  1% (1)
• C
  1% (1)
• D
  4% (3)

Explanation

Designing your application to respect GitHub's rate limits is the only sustainable approach to large-scale API consumption - it ensures your integration remains functional long-term and aligns with GitHub's Terms of Service. Option B (using multiple tokens to bypass limits) violates GitHub's policies and can result in account suspension; rate limits exist per-user/app, and cycling tokens to circumvent them is explicitly prohibited. Option C (permanent caching) sounds appealing but is wrong - stale data causes correctness bugs, and GitHub's API returns cache-control headers precisely to guide appropriate TTLs, not infinite caching. Option D (ignoring secondary rate limits) will get your requests rejected with 403/429 errors, since secondary limits guard against abusive concurrency patterns regardless of primary quota remaining.

Memory tip: Think "work with the rules, not around them" - only option A works within the system. The other three all involve ignoring, bypassing, or misusing limits, which either breaks GitHub's rules or breaks your app.

No community discussion yet for this question.