[Performance] Inefficient GitHub API Request Batching and Rate Limit Handling

[Louser21]

Inefficient GitHub API Request Batching and Rate Limit Handling

Problem

The application performs multiple GitHub API requests for analytics, repositories, commits, and user activity without sufficient batching, caching, or centralized rate-limit handling.

Currently, repeated or concurrent dashboard requests can easily trigger GitHub API rate limits, especially when:

• analyzing multiple repositories
• loading dashboards with several widgets
• refreshing analytics frequently
• multiple users access the platform simultaneously

This can result in partial data loads, failed requests, degraded UX, or temporary API lockouts.

---

Why This Matters

GitHub enforces strict API rate limits, particularly for unauthenticated or heavily repeated requests.

Without efficient request orchestration:

• dashboards become unreliable
• users receive inconsistent analytics
• API quotas are exhausted unnecessarily
• scalability becomes difficult as traffic grows

This issue directly impacts production reliability and long-term maintainability of the platform.

---

Current Risks

• Duplicate API calls for identical resources
• Serial request chains increasing latency
• Missing shared cache layer
• Lack of request deduplication
• Excessive refetching during re-renders/navigation
• Poor handling of GitHub rate-limit headers
• Increased failure probability during peak usage

---

Suggested Improvements

Backend Improvements

• Introduce centralized API request manager
• Add request batching for related GitHub endpoints
• Implement shared in-memory caching (LRU/Redis)
• Use conditional requests with ETag headers
• Prevent duplicate concurrent fetches for identical resources

Frontend Improvements

• Debounce repeated analytics requests
• Cache previously fetched responses
• Avoid unnecessary refetches on component re-renders
• Add graceful retry/backoff handling

Rate Limit Handling

• Track GitHub rate-limit headers globally
• Add proactive throttling before exhaustion
• Surface meaningful fallback/error states to users

---

Expected Outcome

• Reduced GitHub API consumption
• Faster dashboard loading
• Improved scalability under concurrent usage
• More stable analytics rendering
• Better resilience against API failures/rate limits

---

Difficulty

Advanced

---

Why This Is Valuable

This is a production-grade architectural improvement that significantly improves reliability and scalability.

It requires:

• async request orchestration
• caching strategies
• API systems understanding
• frontend/backend coordination

Making it a strong intermediate-to-advanced contribution suitable for GSSOC.

---

Duplicate Check

I checked existing Issues, PRs, Discussions, and repository TODOs and could not find an already raised issue specifically addressing:

• centralized API batching
• request deduplication
• intelligent caching
• architectural GitHub rate-limit prevention