[feat]: Add Redis for Caching and Distributed Rate Limiting
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 0
- Forks
- 3
- PR merge metrics
- No merged PRs in 30d
Description
### Problem
Heavy commands repeatedly call external services and scraping logic, which can increase latency and API pressure.
### Proposed Work
- Add Redis integration (local/dev + production configuration).
- Cache frequently requested command results (for example profile lookups) with sensible TTL values.
- Store command cooldown/rate-limit state in Redis to support multiple bot instances.
### Acceptance Criteria
- Repeated requests within TTL hit Redis cache instead of external API/scraper paths.
- Cooldown/rate-limit logic still works correctly across restarts and multi-instance deployments.
- Cache keys and TTL strategy are documented.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No files, tests, or entry points are named. Start by mapping the command handlers that call external services or scraping logic and locating the existing cooldown/rate-limit state; then review configuration and deployment setup. Done means Redis-backed caching and shared rate limits satisfy the listed acceptance criteria, including documented cache keys and TTLs.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, redis
- Domain
- backend, distributed-systems, performance
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100