[ENHANCEMENT] Implement API Rate Limiting for CoinGecko Integration

[NithinRegidi]

Current behavior

Problem Statement

Current Situation

CryptoHub makes unrestricted API calls to CoinGecko without client-side rate limiting, causing:

• API Rate Limit Violations: Exceeding CoinGecko's rate limits (10-30 calls/min)
• Service Disruptions: Temporary bans or degraded service
• Poor User Experience: Failed requests during high usage periods
• Inefficient Resource Usage: Redundant API calls without proper caching

Impact

• API Reliability: Risk of being rate-limited or banned by CoinGecko
• User Experience: Failed cryptocurrency data loading
• Performance: Slow responses due to rate limit delays
• Scalability: Issues when multiple users access the app simultaneously

Evidence

• src/context/CoinContext.jsx makes direct API calls without queuing
• src/CryptoChatbot/coinGeckoService.js lacks rate limiting logic
• React Query is configured but not optimized for rate limiting
• No exponential backoff for failed requests

API Reliability

• Rate Limit Compliance: Stay within CoinGecko's limits (10-30 calls/min)
• Service Continuity: No more temporary API bans
• Better Resilience: Handle API outages gracefully
• Cost Efficiency: Reduce unnecessary API calls

Why This Issue?

• Critical for API-dependent applications like CryptoHub
• Addresses real-world rate limiting challenges
• Improves user experience significantly
• Good opportunity to work with React Query advanced features

I would like to implement API rate limiting for CoinGecko integration to ensure reliable cryptocurrency data access. Please let me know if this proposal is acceptable or needs modifications.

Ready to optimize API usage!

Proposed improvement

Proposed Solution

Approach

Implement comprehensive client-side rate limiting for CoinGecko API calls using:

1. Request queuing system to manage API call frequency
2. Exponential backoff for failed requests
3. Enhanced local caching strategy
4. Leverage React Query's built-in retry and caching features

Technical Implementation

Phase 1: Rate Limiting Infrastructure

• Implement request queuing with configurable limits
• Add exponential backoff for rate limit errors
• Create centralized API client wrapper

Phase 2: Enhanced Caching

• Extend React Query caching configuration
• Implement smart cache invalidation
• Add offline support with stale data

Phase 3: Error Handling & UX

• Graceful handling of rate limit errors
• User feedback during rate limiting
• Automatic retry with progressive delays

Priority

High (affects many users)

Component affected

None

[github-actions]

## 🔁 Possible Duplicate Issue

Hi @NithinRegidi 👋,

This issue appears to be **similar to an existing one**:

👉 **#336 – [ENHANCEMENT]**

### ✅ What should you do?
- If this is the same problem, please continue the discussion on the existing issue.
- If it's different, kindly explain **how this issue is unique** so maintainers can review it.

Keeping issues clean helps everyone contribute better and faster.  
Thanks for your understanding! 🙌

---

[NithinRegidi]

@KaranUnique

✅ Required Labels (Both Mandatory)

Before a PR is merged, it must contain exactly two labels:

1. apertre3.0 – Identifies the PR as part of the Apertre 3.0 program
2. One Difficulty Label – easy / medium / hard

⚠️ PRs without both labels will NOT be considered valid, even if the code is correct.

[NithinRegidi]

@Raamgopal8 bro please add apertre3.0 and difficulty label then I can work on it

[Raamgopal8]

@NithinRegidi Are you working this issue.

[NithinRegidi]

@Raamgopal8 Yes, I'm interested to work on this issue, Can I

[NithinRegidi]

@Raamgopal8 Please also add difficulty label also as Easy/Medium/Hard based on issue

[Raamgopal8]

@NithinRegidi Label will be assigned upon merging.