Implement Rate Limiting Middleware

[Just-Bamford]

Description

Problem

The TipForge backend exposes public and authenticated API routes that can receive a high volume of requests in a short period of time. Without a centralized rate-limiting mechanism, a single client could generate excessive traffic, consume server resources, abuse expensive endpoints, or degrade availability for other users.

Different endpoints also have different resource requirements. A health check, creator profile lookup, authentication endpoint, and payment-related endpoint should not necessarily share the same request limits.

The backend currently needs a consistent mechanism for controlling request frequency while providing clients with enough information to handle rate-limit responses correctly.

Solution

Implement a reusable rate-limiting middleware for the Fastify server.

The middleware should support configurable limits based on route classification and identify clients using an appropriate request identifier such as IP address, authenticated user ID, or API key where applicable.

Rate-limit configuration should be centralized rather than hardcoded across individual routes. The implementation should make it possible to define stricter limits for sensitive or resource-intensive endpoints while allowing higher limits for lightweight public endpoints.

When a client exceeds its configured limit, the API should return 429 Too Many Requests together with standard rate-limit metadata and retry information.

The implementation should also support route exemptions for endpoints that should not participate in rate limiting, such as internal health checks or other explicitly approved routes.

The middleware must work correctly in the expected deployment environment, including deployments where requests pass through a reverse proxy.

Acceptance Criteria

• Implement a reusable Fastify rate-limiting middleware/plugin.
• Define configurable rate-limit policies for different route classes.
• Support separate limits for public, authenticated, and sensitive endpoints.
• Identify clients consistently using IP addresses and authenticated identities where appropriate.
• Return 429 Too Many Requests when a configured limit is exceeded.
• Include appropriate rate-limit and retry metadata in responses.
• Support configurable route exemptions.
• Ensure proxy configuration does not cause all users to be incorrectly identified as the same client.
• Keep rate-limit configuration separate from route implementation.
• Add automated tests for requests within the limit.
• Add automated tests for requests exceeding the limit.
• Add tests covering exempt routes.
• Add tests covering different route classes and their respective limits.
• Document the middleware configuration and rate-limit behavior.
• Ensure existing API behavior and tests continue to pass.

Note for Contributors

Keep the implementation modular and deployment-compatible. Avoid coupling rate-limit logic directly to individual controllers or services. The middleware should be reusable as additional API routes and services are introduced.