Overview
Add API rate limiting to InterruptIQ to protect the backend from excessive requests, accidental request floods, and basic abuse.
The rate-limiting layer should be implemented as reusable Fastify middleware/plugin functionality and should not require changes to the business logic of individual modules.
Problem
InterruptIQ currently exposes multiple API endpoints for authentication, events, decisions, memory retrieval, critic evaluation, and other operations.
Without request throttling, a client can repeatedly call expensive endpoints such as:
/api/v1/auth/*
/api/v1/events/*
/api/v1/decision/*
/api/v1/memory/retrieve
/api/v1/critic/evaluate
This can unnecessarily increase CPU, database, Redis, and embedding/LLM workloads.
Proposed Solution
Implement a reusable API rate-limiting layer for Fastify.
The implementation should:
- Apply configurable request limits.
- Identify clients using IP address and/or authenticated user identity.
- Return HTTP
429 Too Many Requests when the limit is exceeded.
- Include appropriate rate-limit response headers.
- Support different limits for sensitive/expensive endpoints where appropriate.
- Keep configuration environment-driven.
- Avoid hardcoding limits directly inside route handlers.
- Provide clear error responses when a request is throttled.
- Work correctly with the existing Redis infrastructure when available.
- Gracefully fall back to local/in-memory limiting for development if Redis is unavailable.
Suggested Configuration
Add environment variables similar to:
RATE_LIMIT_ENABLED=true
RATE_LIMIT_MAX=100
RATE_LIMIT_WINDOW_MS=60000
Overview
Add API rate limiting to InterruptIQ to protect the backend from excessive requests, accidental request floods, and basic abuse.
The rate-limiting layer should be implemented as reusable Fastify middleware/plugin functionality and should not require changes to the business logic of individual modules.
Problem
InterruptIQ currently exposes multiple API endpoints for authentication, events, decisions, memory retrieval, critic evaluation, and other operations.
Without request throttling, a client can repeatedly call expensive endpoints such as:
/api/v1/auth/*/api/v1/events/*/api/v1/decision/*/api/v1/memory/retrieve/api/v1/critic/evaluateThis can unnecessarily increase CPU, database, Redis, and embedding/LLM workloads.
Proposed Solution
Implement a reusable API rate-limiting layer for Fastify.
The implementation should:
429 Too Many Requestswhen the limit is exceeded.Suggested Configuration
Add environment variables similar to: