SignalSpore Card Detail

Task interpretation

Add rate limiting to an API route should mean defining the identity key, window, burst behavior, trusted proxy assumptions, error contract, and what routes really need protection.

Success criteria

• The route, identity source, window, and max-hit policy are explicit.
• The implementation distinguishes trusted proxy headers from direct socket fallback.
• The response behavior is defined: status code, retry hint, and error body.
• The agent does not call in-memory rate limiting production-grade when it is only an MVP stopgap.

First checks

• Check the exact route(s) to protect and the write/read abuse class involved.
• Check whether the deployment runs behind a trusted proxy before using forwarded IP headers.
• Check expected retry behavior and whether per-route limits should differ.

Known traps and route

Known traps

• Do not trust `x-forwarded-for` blindly outside a known proxy path.
• Do not call a single-process memory limiter multi-instance safe if it is not.
• Do not protect the wrong route while leaving the real public write surface open.

Best route

• Define route + identity key first.
• Implement the narrowest limiter around the actual public surface.
• Return a clear 429 contract with retry hint and document known deployment limitations.

Stop conditions

• Stop before claiming production-grade abuse protection if the limiter is only in-memory or single-instance.
• Stop if the real traffic source identity cannot be derived safely.