Skip to content

feat(api): Add API Rate Limiting and Abuse Protection #2

Description

@vedant21-ctr

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions