Implement Rate Limiting using Redis

[meshackyaro]

Description

This issue aims to address the implementation of Implement Rate Limiting using Redis.

The core objective is to: Protect public endpoints against spam by implementing a 100 req/min limit.

By completing this feature, we will ensure that the TrustFlow protocol maintains its high standards for security, usability, and decentralized logic. This issue requires careful attention to the Backend architecture and adherence to the existing project conventions.

When picking up this issue, please ensure you document any new dependencies or architectural decisions made during development.

Component

Backend

Difficulty

🔴 Hard

Tasks

• Review Node.js API architecture in backend/
• Implement logic for: Implement Rate Limiting using Redis
• Write unit tests for the new endpoints using Supertest
• Update Swagger terminology / OpenAPI specs
• Verify PostgreSQL queries are optimized
• Run npm run lint

Acceptance Criteria

• Feature accurately implements the objective: Protect public endpoints against spam by implementing a 100 req/min limit.
• Any PR that introduces TypeScript/Rust errors is automatically blocked
• CI pipeline runs in under 3 minutes per PR
• Code is properly reviewed and approved by codeowners

Estimated Time

1-3 days

[Chidubemkingsley]

I'd like to take on this issue. I have experience building and maintaining backend services with Node.js and TypeScript, including implementing middleware, API security controls, Redis integrations, automated testing, and CI workflows. I'm particularly interested in improving the reliability and resilience of public-facing services.

For this task, I can review the existing architecture in backend/ to ensure the rate-limiting solution aligns with the current design patterns and project conventions. I plan to implement a Redis-backed rate limiter capable of enforcing the 100 requests/minute policy while maintaining good performance and scalability. I'll carefully consider edge cases such as concurrent requests, distributed deployments, and proper handling of rate-limit responses.

In addition to the implementation itself, I'll add and update unit tests using Supertest to ensure the new behavior is properly validated and does not introduce regressions. I'll also review and update the Swagger/OpenAPI specifications where necessary so that the API documentation accurately reflects the changes. Furthermore, I'll examine the affected PostgreSQL interactions to ensure query performance remains efficient and that the new functionality does not negatively impact the overall request flow.

Throughout the development process, I'll document any newly introduced dependencies and architectural decisions to make future maintenance easier. Before submitting the PR, I'll ensure the codebase passes linting and existing checks, and I'll strive to keep the implementation clean, modular, and easy to review while maintaining compatibility with the project's CI requirements and code quality standards.

[grantfox-oss]

🦊 GrantFox — @Chidubemkingsley has been assigned to this issue as part of the Official Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #37)
2. Your PR will be reviewed by the trustflow-protocol maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign campaign!

@Chidubemkingsley's PR #159 was approved and merged by @meshackyaro.

🏆 @Chidubemkingsley: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (188 total points). Track your full progress on GrantFox.

👏 Great work, @Chidubemkingsley! Keep contributing to trustflow-protocol.