Backend: add per-API-key sliding-window rate limiting layered over the global IP limiter

[Baskarayelu]

📋 Description

rate-limit.ts applies a global limiter (via rate-limiter-flexible), and apiKeyAuth.ts authenticates service callers. There is no per-API-key sliding-window limit, so one key can consume the entire global budget and starve others.

Why this matters: fairness across service consumers requires per-principal limits. A per-key sliding window layered over the global IP limiter prevents a single noisy integration from degrading everyone else.

🎯 Requirements & Context

• Add a per-API-key limiter keyed by the authenticated key id from apiKeyAuth.
• Use a sliding-window algorithm with a configurable per-key rate (default documented).
• Return 429 with Retry-After via the structured error handler; keep the global limiter as an outer bound.
• Surface per-key limit headers and expose limits in the status endpoint (statusService.ts).

Context & constraints

• TypeScript, Express 5, rate-limiter-flexible; jest + supertest. Anonymous (no key) traffic falls back to the global IP limit only.

🛠️ Suggested Execution

git checkout -b feature/per-key-rate-limit
npm --prefix backend test -- rate-limit

• Edge cases: key at exactly the limit; window roll-over; missing key uses global only; two keys isolated from each other.

Example commit message

feat(backend): add per-API-key sliding-window rate limiting

Layers a per-principal limiter over the global IP limiter so one key cannot
starve others; returns 429 with Retry-After.

✅ Acceptance Criteria & Guidelines

Requirement	Target
Per-key sliding window + global outer bound	Required
429 + Retry-After + isolation	Required
Test coverage	≥ 95% of new logic
jest + lint clean	Required
Timeframe	96 hours from assignment

💬 Community & Support

Join Discord: https://discord.gg/VpngvTjWa — comment to claim. 🚀